Groups do introduce complexities in the permissions of individual users. Suppose user M_Haneef has been granted SELECT and UPDATE permissions on a specific table individually, but is also a member of two groups, one of which has no access to the table at all, and one of which has only SELECT access. What are the permissions in effect for this user?
This is how Sybase IQ determines whether a user ID has permission to carry out a specific action:
If the user ID has DBA permissions, the user ID can carry out any action in the database. If the user has an authority described in “Authorities”, the user has the permissions associated with that authority.
Otherwise, permission depends on the permissions assigned to the individual user. If the user ID has been granted permission to carry out the action, then the action is allowed to proceed.
If no individual settings have been made for that user, permission depends on the permissions of each of the groups of which the user is a member. If any of these groups has permission to carry out the action, the user ID has permission by virtue of membership in that group, and the action is allowed to proceed.
If you do not want a specific user to access a particular table, view, or procedure, then do not make that user a member of a group that has permissions on that object.
This approach minimizes problems associated with the order in which permissions are set.
