Microsoft SQL Server 2008 R2 Unleashed- P39 pps

One way to do it is to select the Server object from the list of object types when adding permissions for a specific login.. To demonstrate the differences between object types available

FIGURE 11.10 Server-level permissions

FIGURE 11.11 The Add Objects window

All Objects of the Types option at the server level You can see that the available objects

are all scoped at the server level

If the endpoints objects are selected, the securables grid is populated with all the available

endpoints that have permissions to manage Figure 11.13 shows the Login Properties

window with the endpoints securables populated The TSQL Named Pipes securable is

selected, which allows you to specify the explicit permissions for the securable in the

bottom grid In this example, the Grant and With Grant check boxes have been selected

for the control permission This gives the login named Chris the right to control the

Named Pipes endpoint and also allows him to grant this control right (because With Grant

is selected) to other logins

The examples we just walked through are related to the assignment of explicit permission

on a specific instance of a securable You can also apply server permissions at a higher

FIGURE 11.12 Server-level object types

FIGURE 11.13 Server-level securables

level For example, you might want to specify permissions for a login to allow that login

to control all server endpoints instead of specific endpoints You can accomplish this in

several ways One way to do it is to select the Server object from the list of object types

when adding permissions for a specific login Another way is to right-click the server

name in the Object Explorer and select Properties The Server Properties window that

appears has a Permissions page that lists all the logins for the server, along with the

macro-level permissions scoped for the server Figure 11.14 shows the Server Properties

window with the login Chris selected The explicit permissions listed in this case are at a

higher level and are not just for one instance The example shown in Figure 11.14 allows

FIGURE 11.14 The Server Properties window’s Permissions page

Using SSMS to Manage Permissions at the Database Level

The same type of hierarchy exists with permissions at the database level as at the server

level You can apply permissions at a high level to affect many objects of a particular type,

or you can apply them on a specific object You can also manage the permissions at the

database level on a specific database user, or you can manage them on the database across

many users

To demonstrate the differences between object types available at the database level, let’s

first look at managing permissions for a specific database user As with logins, you can

right-click a database user and select Properties On the Properties window that appears,

you select the Securables page, and you get a screen to assign permissions that is very

similar to the login permissions screen The difference at the database level is in the object

types available for selection Figure 11.15 shows the object types available when you

choose the All Objects of Types choice during the addition of securables for a database user

When a low-level object type such as a table or stored procedure is selected, you are able

to apply explicit permissions to a specific object instance Figure 11.16 shows an example

of low-level securables available when the Table object type is selected

FIGURE 11.15 Database-level object types

FIGURE 11.16 Low-level database securables

FIGURE 11.17 High-level database securables

Using SSMS to Manage Permissions at the Object Level

The last permission assignment we look at is the object level SSMS enables you to select a

specific object instance in the Object Explorer and assign permissions to it This method

allows you to navigate to the object you want via the Object Explorer tree and assign

permissions accordingly Figure 11.18 shows the Object Explorer tree expanded to the

Stored Procedures node A specific stored procedure has been right-clicked, and the

Properties option has been selected

The Properties window has a page dedicated to permissions You can select the

Permissions page and then select the users or roles you want to add for the specific object,

such as a stored procedure Figure 11.19 shows the Permissions page with a user named

Chris added to the Users or Roles window at the top of the page The bottom portion of

the page shows explicit permissions for the user Chris, which includes a DENY permission

on the stored procedure selected

FIGURE 11.18 Object-level permissions selected via Object Explorer

FIGURE 11.19 Object-level permissions

As you saw in the SSMS Permissions pages, three options exist for assigning every

permis-sion: GRANT, DENY, and REVOKE Each option has its own T-SQL statements that can be used

to manage permissions as well The simplified syntax for the GRANT command is as follows:

GRANT { ALL [ PRIVILEGES ] }

| permission [ ( column [ , n ] ) ] [ , n ]

[ ON [ class :: ] securable ] TO principal [ , n ]

[ WITH GRANT OPTION ] [ AS principal ]

This basic GRANT syntax is similar to that in SQL Server 2000, but the addition of many

permissions and securables in SQL Server 2005 and SQL Server 2008 has expanded the

scope of the command SQL Server 2005 also introduced the WITH GRANT option which

allows a permission to be granted to a principal and allows the principal to grant that

permission to another principal The WITH GRANT option has been carried forward to SQL

Server 2008 and is a good way to delegate administrative functions to others

The simplified syntax for the DENY and REVOKE commands is as follows:

DENY { ALL [ PRIVILEGES ] }

| permission [ ( column [ , n ] ) ] [ , n ]

[ ON [ class :: ] securable ] TO principal [ , n ]

[ CASCADE] [ AS principal ]

REVOKE [ GRANT OPTION FOR ]

{

[ ALL [ PRIVILEGES ] ]

|

permission [ ( column [ , n ] ) ] [ , n ] }

[ ON [ class :: ] securable ]

{ TO | FROM } principal [ , n ]

[ CASCADE] [ AS principal ]

You can see that the simplified syntax for DENY and REVOKE is similar in structure to the

GRANT statement All the statements must identify the permission, securable, and principal

that will receive the permission

The ALL clause has been deprecated in SQL Server 2008 If ALL is specified, it does not

affect all permissions on the object; it affects only a subset of the permissions related to

the securable The subset of permissions is dependent on the securable

The following examples demonstrate several different types of permissions you can

manage by using T-SQL commands:

Grant permissions to create a table

to a user named Chris

GRANT CREATE TABLE TO Chris

Grant ALL permissions on a stored procedure

to a database role named TestDBRole

GRANT ALL ON dbo.uspGetBillOfMaterials TO TestDBRole

DENY UPDATE permission on the Customer table

to user named Laura

DENY UPDATE ON OBJECT::sales.customer TO Laura

REVOKE UPDATE permissions on the Customer table

to user named Laura

REVOKE UPDATE ON OBJECT::sales.customer TO Laura

There are many different flavors of the GRANT, DENY, and REVOKE statements, depending on

the securable they are affecting Books Online outlines the syntax for each securable and

the permissions that can be applied

Remember that you can use the Script option to generate the T-SQL from SSMS The Script

button is available when you’re managing permissions, and using it is a great way to

familiarize yourself with the T-SQL that is used to effect changes You can select the

permissions you want to apply via the GUI screen and then click the Script button to

generate the T-SQL

The Execution Context

The execution context determines what permissions are checked when statements are

executed or actions are performed on the database server By default, the execution context

is set to the principal connected to the server or database If a user named Chris connects

to the AdventureWorks2008 database, the permissions assigned to Chris are checked

In SQL Server 2008, you can change the execution context so that permissions are

checked for a principal other than that to which you are connected You can make this

change in execution context (called context switching) explicitly or implicitly.

selecting from the Sales.Customer table

DENY SELECT ON sales.customer TO Public

We can check that user Laura cannot select from the

Sales.Customer table using the EXECUTE AS statement

EXECUTE AS USER = ‘laura’

SELECT TOP 1 * FROM sales.customer

Revert to the previous execution context

REVERT

You can also do explicit context switching at the login level You can use the EXECUTE AS

statement to switch the execution context to another login instead of a user

Context switching is linked to the IMPERSONATE permission As an administrator, you can

grant IMPERSONATE to a login or user to enable that user to execute as that user For

example, an administrator can temporarily enable another login to run in the same

execu-tion context by using the IMPERSONATE permission and EXECUTE AS statement The

follow-ing example demonstrates the assignment of the IMPERSONATE permission to a login

named Laura:

Chris grants the right to Laura to impersonate him

GRANT IMPERSONATE ON LOGIN::[chris] TO [laura]

GO

Laura can then connect with her login and use

the EXECUTE AS command to run commands that

normally only Chris has permission to run

EXECUTE AS Login = ‘Chris’

DBCC CHECKDB (AdventureWorks2008)

SELECT USER_NAME()

Revert back to Laura’s execution context

REVERT

SELECT USER_NAME()

Laura can now use EXECUTE as Chris, who is an administrator This capability can be

particularly useful when a user or login has many custom permissions that would take a

lot of time to establish for another user or login

Implicit Context Switching

With implicit context switching, the execution context is set within a module such as a

stored procedure, trigger, or user-defined function The EXECUTE AS clause is placed in the

module and is set to the user that the module will be run as The context switch is

implicit because the user who runs the module does not have to explicitly specify the

context before running the module The context is set within the module

The EXECUTE AS clause has several different options to establish the execution context All

modules are able to set the context to a specific user or login Functions, stored

proce-dures, and Data Manipulation Language (DML) triggers can also execute as CALLER, SELF,

or OWNER DDL triggers can run as CALLER or SELF Queues can run as SELF or OWNER The

CALLER option is the default, and it runs the module in the context of the user who called

the module The SELF option causes the module to run in the context of the user or login

that created the procedure The OWNER option causes the module to run in the context of

the current owner of the module

The following example demonstrates the creation and execution of a stored procedure

with the EXECUTE AS clause on a specific user named Chris:

CREATE PROCEDURE dbo.usp_TestExecutionContext

WITH EXECUTE AS ‘chris’

AS SELECT USER_NAME() as ‘User’

Set the user to someone other than chris to test the

implicit EXECUTE AS

SETUSER ‘DBO’

EXEC usp_TestExecutionContext

/*Results of the prior execution

User

-chris

*/

This example shows that the USER_NAME retrieved in the stored procedure is Chris,

regard-less of who executed the procedure

Implicit execution context can be particularly useful in situations in which permissions

cannot be granted to a user directly For example, TRUNCATE TABLE permissions cannot be

granted explicitly to a user, but a database owner can run this command Instead of

grant-ing dbo rights to a user needing TRUNCATE permissions, you can create a stored procedure

that does the truncation You can create the stored procedure with the execution context

of dbo, and you can grant the user rights to execute the stored procedure that does the

truncation When you use this method, the user can perform the truncation but does not

have any of the other permissions related to a database owner