4. Revoking and Denying Object Permission with Code
Revoking and denying object permissions
uses essentially the same syntax as granting permission. The following
statement revokes select permissions from Jose on the Sales.SalesHeader table:
REVOKE All ON Sales.SalesHeader TO [AgileBay\Jose];
If the permission included the WITH GRANT option, then the permission must be revoked or denied with the CASCADE option so that the WITH GRANT OPTION will be removed. The following command denies select permissions from Jose on the Person table:
DENY SELECT ON Person.Person TO [AgileBay\Jose]CASCADE
Because using CASCADE can revoke not only the WITH GRANT OPTION permission, the DBA can also get rid of the ability to GRANT but must first get rid of the permission including WITH GRANT OPTION and then re-grant the original permission, but this time without specifying the WITH GRANT OPTION.
5. The Public Role
The public role is a fixed role, but it
can have object permissions like a user-defined role. Every user is
automatically a member of the public role and cannot be removed, so the
public role serves as a baseline or minimum permission level.
Caution
Be careful when applying permissions to
the public role because it affects everyone except members of the
sysadmin role. Denying access to the public role blocks all users, even
object owners, from accessing the data. Most importantly, remember that
granting access to the public role allows all users to access the data.
The exception is any login that maps to dbo and members of the sysadmin
fixed server role because they bypass all security permissions.
6. Managing Roles with Code
Creating user-defined roles with code involves using the sp_addrole system stored procedure. The name can be up to 128 characters and cannot include a backslash, be Null,
or be an empty string. By default, the roles will be owned by the dbo
user. However, you can assign the role an owner by adding a second
parameter. The following code creates the Manager role:
CREATE ROLE [Manager]
Result:
New Manager role added.
The counterpart of creating a role is removing it. A role may not be dropped if any users are currently assigned to it. The DROP ROLE command removes the role from the database:
DROP ROLE [Manager]
Result:
Manager role dropped.
Note
sp_addRoleMember and sp_dropRoleMember are deprecated features. Microsoft advises using ALTER instead.
After a role has been created, users may be assigned to the role by means of the ALTER ROLE command. The following code assigns the Windows login for Jose to the Manager role:
ALTER ROLE [Manager] ADD MEMBER [AgileBay\Jose]
Result:
The Windows login [AgileBay\Jose] added to the Manager role.
The ALTER ROLE command is also used to remove a user from an assigned role. The following code removed Jose from the Manager role:
ALTER ROLE [Manager] DROP MEMBER [AgileBay\Jose];Result:
The Windows login [AgileBay\Jose] removed from the Manager role.
7. Hierarchical Role Structures
If the security structure is complex,
then a powerful permission-organization technique is to design a
hierarchical structure of user-defined database roles. In other words,
you can nest user-defined database roles.
- The worker role may have limited access.
- The manager role may have all worker rights plus additional rights to look up tables.
- The administrator role may have all manager rights plus the right to perform other database-administration tasks.
To accomplish this type of design, follow these steps:
1. Create the worker role and set its permissions.
2. Create the manager role and set its permissions. Add the manager role as a user to the worker role.
3. Create the admin role. Add the admin role as a user to the manager role.
The advantage of this type of security
organization is that a change in the lower level affects all upper
levels. As a result, administration is required in one location, rather
than dozens of locations.
8. Object Security and Management Studio
Because object permissions involve
users, roles, and objects, they can be set from numerous places within
Management Studio. It's almost a maze.
From the Object List
Follow these steps to modify an object's permissions:
1. From an
object node (tables, views, stored procedures, or user-defined
functions) in the Object Browser, from the context menu select
Properties to open the Properties dialog for that object type.
2. Click the Permissions page to open the Object Properties dialog.
As with setting statement permissions on the
Database Properties Security tab, you can select grant, with grant, or
deny. The object list at the top of the dialog lists all the objects in
the database. This list can be used to quickly switch to other objects
without backing out of the form to the console and selecting a
different object.
The Columns button at the bottom opens the Column
Permissions dialog. Select the user, and then click the button to set
the columns permission for that user. Only select and update
permissions can be set at the column level because inserts and deletes
affect the entire row.
From the User List
From the list of database users in
Management Studio, select a user and double-click, or select Properties
from the right-click context menu. The Database User Properties dialog
is used to assign users to roles.
Clicking the Properties button opens the properties of the selected role.
Clicking the Permissions button opens the
Permissions tab of the Database User Properties dialog. This dialog is
similar to the Permissions tab of the Database Object Properties dialog.
Unfortunately, the list of objects appears to be
unsorted, or only partially sorted, and the grid headers don't re-sort
the list of objects. This dialog also desperately needs a select all
functions and other features, such as those in Access's permissions
forms.
From the Role List
The third way to control object
permissions is from the database role. To open the Database Role
Properties dialog, double-click a role in the list of roles, or select
Properties from the right-click context menu. You can use the Database
Role Properties dialog to assign users or other roles to the role, and
to remove them from the role.
The Permissions button opens the
Permissions dialog box for the role. This form operates like the other
permission forms except that it is organized from the role's
perspective.