SQL Server 2000 Stored Procedure Programming phần 8 pps

514 SQL Server 2000 Stored Procedure Programming The Database Access tab controls the databases the user can access and the user’s membership in roles: You can also grant logins using stored procedures. You can use sp_grantlogin to create a login on SQL Server. To give a Windows user access to a SQL Server, only the name of the user is required as a parameter: exec sp_grantlogin 'Accounting\TomB' However, when you create a login for SQL Server, you usually specify an authentication password and a default database as well: exec sp_grantlogin 'TomB', 'password', 'Asset' Granting Database Access As we have shown, database access can be granted to a login during the login’s creation. There is also a way to grant access to additional databases after the login has been created. Database users can be managed from the Users node of a database in Enterprise Manager. You can both manage existing users and create new users. Login names have to be selected from the list box. The User Name is set by default to the name of the login. This default is not required, but it simplifies user management. In the Database Role Membership section, you check all databases to which you want to grant the user membership: You can perform the same operation from Transact-SQL. To grant access to the database, use sp_grantdbaccess: exec sp_grantdbaccess 'TomB', 'TomB' You can review access using sp_helpusers and revoked using sp_revokedbaccess. To assign a user to a user-defined database role, you issue a command such as exec sp_addrolemember 'TomB', 'Management' Chapter 11: Interaction with the SQL Server Environment 515 You can review membership using sp_helprolemember and revoke it using sp_droprolemember. You can create roles using sp_addrole: exec sp_addrole 'Management' You can remove roles using sp_droprole. To view a list of roles, use sp_helpfixeddbroles and sp_helproles. Assigning Permissions The system of permissions controls user and role access to database objects and statements. Permissions can exist in one of following three states: ▼ Granted ■ Denied ▲ Revoked Granted means that a user has permission to use an object or statement. Denied means that a user is not allowed to use a statement or object, even if the user has previously inherited permission (that is, he is member of a role that has permission granted). Physically, a record is stored in the sysprotects table for each user (or role) and object (or statement) for which permission has been granted or denied. When a permission is Revoked, records that were stored for that security account (that is, the records granting or revoking permissions) are removed from the sysprotects table. Because of their physical implementation, permissions are cumulative. For example, a user can receive some permissions from one role and missing permissions from some other role. Or, the user can lose some permissions that have been granted to all other members of a role. You can control statement permissions from the Permissions tab of a database’s Properties dialog. You can set object permissions using the Permissions button in a database object’s Properties dialog. In both cases, you see a list of users and roles: 516 SQL Server 2000 Stored Procedure Programming Chapter 11: Interaction with the SQL Server Environment 517 An administrator can grant (þ), deny ( ), or revoke (ý) permissions. Grant Statement To grant statement permission, an administrator can issue a Grant statement with the following syntax: Grant {ALL | statement_name_1 [, statement_name_2 , … statement_name_n ] } To account_1 [, account_2 , … account_n ] To grant object permission, an administrator can issue a Grant statement with the following syntax: Grant {All [Privileges]| permission_1 [, permission_2 , … permission_n ]} { [ column_1 , column_2 , … column_n ] ON {table | view } | On {table | view } [ column_1 , column_2 , … column_n ] | On { stored_procedure } } To account_1 [, account_2 , … account_n ] [With Grant Option] As {group | role} 518 SQL Server 2000 Stored Procedure Programming The following statement allows JohnS (SQL Server login) and TomB from the Accounting domain (Windows domain user) to create a table in the current database: Grant Create Table To JohnS, [Accounting\TomB] The following statement allows members of the AssetOwners role to view, store, delete, and change records in the Inventory table: Grant Select, Insert, Update, Delete On Inventory To AssetOwners Deny Statement The Deny statement is used to negate permissions. Its syntax is basically the same as the syntax of the Grant statement (except that the keyword Deny is used). The following statement prevents TomB from the Accounting domain from creating a database: Deny Create Database To [Accounting\TomB] The following statement prevents JohnS from deleting and changing records from the Inventory table, even though he has inherited rights to view, store, delete, and change records as a member of the AssetOwners role: Deny Update, Delete On Inventory To JohnS Revoke Statement The Revoke statement is used to deactivate statements that have granted or denied permissions. It has the same syntax as the Grant and Deny statements (except that the keyword Revoke is used). It is easy to understand that permission can be removed using this statement. It is a little more challenging to understand how a permission can be granted by revoking it. Let’s review an example in which a user JohnS is a member of the AssetOwners role, which has permission to insert, update, select, and delete records from the Inventory table. exec sp_addrolemember 'JohnS', 'AssetOwners' The Administrator then decides to deny JohnS permission to delete and update records from Inventory: Deny Update, Delete On Inventory To JohnS After a while the administrator issues the following statement: Revoke Update, Delete On Inventory To JohnS In effect, this command has granted Update and Delete permission on the Inventory table to JohnS. Since the Revoke statement removes records from the sysprotects table in the current database, the effect of the Revoke statement is to return permissions to their original state. Naturally, this means that the user will not have access to the object (or statement). In that respect, its effect is similar to the Deny statement. However, there is a major difference between revoked and denied permissions: the Revoke statement does not prevent permissions from being granted in the future. Synchronization of Login and User Names In the section earlier in this chapter called “Database Deployment,” I mentioned the common problem of mismatches between users and logins when databases are copied from one server to another. The problem is a product of the fact that records in the sysusers table of the copied database point to the records in the syslogins table with matching loginid field. One solution is to create and manage a script that recreates logins and users on the new server after a database is copied. Chapter 11: Interaction with the SQL Server Environment 519 SQL Server also offers the sp_change_users_login procedure. You can use it to display mapping between user and login: exec sp_change_users_login @Action = 'Report', @UserNamePattern = 'B%' You can set a login manually for a single user: exec sp_change_users_login @Action = 'Update_one', @UserNamePattern = 'TomB', @LoginName = 'TomB' SQL Server can also match database users to logins with the same name: exec sp_change_users_login @Action = 'Auto_Fix', @UserNamePattern = '%' For each user, SQL Server tries to find a login with the same name and to set the login ID. TIP: sp_change_users_login with ‘Auto_Fix’ does a decent job, but the careful DBA should inspect the results of this operation. Managing Application Security Using Stored Procedures, User-Defined Functions, and Views When a permission is granted on a complex object like a stored procedure, a user-defined function, or a view, a user does not need to have permissions on the objects or statements inside it. We can illustrate this characteristic in the following example: Create Database Test Go sp_addlogin @loginame = 'AnnS', @passwd = 'password', @defdb = 'test' GO 520 SQL Server 2000 Stored Procedure Programming Use Test Exec sp_grantdbaccess @loginame = 'AnnS', @name_in_db = 'AnnS' Go Create Table aTable( Id int identity(1,1), Description Varchar(20) ) Go Create Procedure ListATable as Select * from aTable go Create Procedure InsertATable @Desc varchar(20) as Insert Into aTable (Description) Values (@Desc) Go Deny Select, Insert, Update, Delete On Atable To Public Grant Execute On InsertATable To Public Grant Execute On ListATable To Public Go Chapter 11: Interaction with the SQL Server Environment 521 A table is created along with two stored procedures for viewing and inserting records into it. All database users are prevented from using the table directly but granted permission to use the stored procedures. NOTE: All database users are automatically members of the Public role. Whatever is granted or denied to the Public role is automatically granted or denied to all database users. After this script is executed, you can log in as AnnS in Query Analyzer and try to access the table directly and through stored procedures. Figure 11-4 illustrates such attempts. 522 SQL Server 2000 Stored Procedure Programming Figure 11-4. Stored procedures are accessible even when underlying objects are not Stored procedures, user-defined functions, and views are important tools for implementing sophisticated security solutions in a database. Each user should have permissions to perform activities tied to the business functions for which he or she is responsible and to view only related information. It is also easier to manage security in a database on a functional level than on the data level. Therefore, client applications should not be able to issue ad hoc queries against tables in a database. Instead, they should execute stored procedures. Users should be grouped in roles by the functionality they require, and roles should be granted execute permissions to related stored procedures. Since roles are stored only in the current database, using them helps you avoid problems that occur during the transfer of the database from the development to the production environment (see “Database Deployment” earlier in the chapter). NOTE: There is one exception to the rule we have just described. If the owner of the stored procedure is not the owner of the database objects by the stored procedure, SQL Server will check the object’s permissions on each underlying database object. Usually, this is not an issue because all objects are owned by dbo. Managing Application Security Using a Proxy User Security does not have to be implemented on SQL Server. If the application is developed using three-tier architecture, objects can use roles, users, and other security features of Microsoft Transaction Server (on Windows NT) or Component Services (in Windows 2000) to implement security. Security is sometimes also implemented inside the client application. In both cases, database access is often accomplished through a single database login and user. Such a user is often called a proxy user. Chapter 11: Interaction with the SQL Server Environment 523 [...]... administrators today is the Web SQL Server can create Web pages based on the contents of database tables or generated resultsets SQL Server includes a wizard to generate common Web pages, but it 525 526 SQL Server 2000 Stored Procedure Programming also includes a set of stored procedures for creating and executing Web tasks The result of the wizard and system stored procedures are pages that are far... backup folder and transfer them to a drive on another machine 3 Create a Transact -SQL batch that will create a scheduled job for compressing backup files The job should be scheduled to run once a day CHAPTER 12 XML Support in SQL Server 2000 527 Terms of Use 5 28 SQL Server 2000 Stored Procedure Programming M icrosoft SQL Server has become a giant among the select group of enterprise-ready Relational... various tricks to accomplish this migration, but SQL Server 2000 and SQL Server 7.0 treat database files like any other files It is possible to detach them, copy them, and then attach them to another server Stored procedures are an important tool for managing application, database, and SQL Server security On the system level, you can use system or custom stored procedures to manage logins, users, roles,... Basic The standard ways that SQL Server uses to notify administrators of events that have occurred on a SQL Server is by pager and by e-mail SQL Server can also receive and answer queries by e-mail It is possible to set and use these features from Enterprise Manager, but in cases where more control is needed, developers can use system stored procedures and extended stored procedures An important channel... the entire SQL Server is exposed The other occurs when a developer stores login information in a file or Registry so that it can be changed later Unfortunately, it can also be read by unauthorized persons, and again, SQL Server security is compromised Managing Application Security Using Application Roles Application roles are a new feature that can be used in SQL Server 7.0 and SQL Server 2000 These... different vertical markets SQL Server 2000 also uses XDR for its XML schema Let’s review an example of an XML schema document: 539 540 SQL Server 2000 Stored Procedure Programming . usually define ▼ Formatting ■ Structure ▲ Meaning 530 SQL Server 2000 Stored Procedure Programming 532 SQL Server 2000 Stored Procedure Programming XML Let’s take a look at a simple example. be scheduled to run once a day. 526 SQL Server 2000 Stored Procedure Programming CHAPTER 12 XML Support in SQL Server 2000 527 Terms of Use M icrosoft SQL Server has become a giant among the. stored procedures. Figure 11-4 illustrates such attempts. 522 SQL Server 2000 Stored Procedure Programming Figure 11-4. Stored procedures are accessible even when underlying objects are not Stored