|
Once you understand how to manage permissions for individual users (as described in the previous section), working with groups is straightforward. A group is identified by a user ID, just as a single user is. However, a group user ID has the permission to have members.
When you grant permissions to a group or revoke permissions from a group for tables, views, and procedures, all members of the group inherit those changes. The following authorities are not inherited; you must assign them individually to each of the individual user IDs requiring them:
NoteYou can only specify WITH GRANT OPTION for users. Members of groups do not inherit the WITH GRANT OPTION if it is granted to a group. |
A group is simply a user ID with special permissions. You grant permissions to a group and revoke permissions from a group in exactly the same manner as any other user. See Managing individual user IDs and permissions.
You can construct a hierarchy of groups, where each group inherits permissions from its parent group. That means that a group can also be a member of a group. As well, each user ID may belong to more than one group, so the user-to-group relationship is many-to-many.
The ability to create a group without a password enables you to prevent anybody from connecting to the database using the group user ID.
For more information about this security feature, see Groups without passwords.
For more information about altering database object properties, see Setting properties for database objects.
For more information about granting remote permissions for groups, see Granting and revoking remote permissions.
Creating groups
Granting group membership to existing users or groups
Revoking group membership
Permissions of groups
Referring to tables owned by groups
Groups without passwords
Special groups
Deleting groups from the database