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.
The following permissions are not inheritable:
The following authorities are not inheritable:
You 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 user permissions and authorities.
Granting group membership to existing users or groups
Revoking group membership
Permissions and authorities of groups
Referring to tables owned by groups
Groups without passwords
Deleting groups from the database
|Send feedback about this page via email or DocCommentXchange||Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0|