Once you understand how to manage permissions for individual users (as described in Managing user permissions and authorities), 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.

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.

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. Some authorities are

The ability to create a group without a password enables you to prevent anybody from connecting to the database using the group user ID. See Groups without passwords.

For more information about granting remote permissions for groups, see Granting and revoking remote permissions.

Inheriting permissions and authorities

The following permissions are not inheritable:

The following authorities are not inheritable:

• DBA
• BACKUP
• VALIDATE
• GROUP
• RESOURCE

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 user permissions and authorities.