Teradata Database. SQL Data Control Language

Transcription

1 Teradata Database SQL Data Control Language Release 14.0 B A June 2013

2 The product or products described in this book are licensed products of Teradata Corporation or its affiliates. Teradata, Active Data Warehousing, Active Enterprise Intelligence, Applications-Within, Aprimo, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast, Gridscale, MyCommerce, Raising Intelligence, Smarter. Faster. Wins., SQL-MapReduce, Teradata Decision Experts, "Teradata Labs" logo, "Teradata Raising Intelligence" logo, Teradata ServiceConnect, Teradata Source Experts, "Teradata The Best Decision Possible" logo, The Best Decision Possible, WebAnalyst, and Xkoto are trademarks or registered trademarks of Teradata Corporation or its affiliates in the United States and other countries. Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc. AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc. Apache, Apache Hadoop, Hadoop, and the yellow elephant logo are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. Apple, Mac, and OS X all are registered trademarks of Apple Inc. Axeda is a registered trademark of Axeda Corporation. Axeda Agents, Axeda Applications, Axeda Policy Manager, Axeda Enterprise, Axeda Access, Axeda Software Management, Axeda Service, Axeda ServiceLink, and Firewall-Friendly are trademarks and Maximum Results and Maximum Support are servicemarks of Axeda Corporation. Data Domain, EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation. GoldenGate is a trademark of Oracle. Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company. Hortonworks, the Hortonworks logo and other Hortonworks trademarks are trademarks of Hortonworks Inc. in the United States and other countries. Intel, Pentium, and XEON are registered trademarks of Intel Corporation. IBM, CICS, RACF, Tivoli, and z/os are registered trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds. LSI is a registered trademark of LSI Corporation. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States and other countries. NetVault is a trademark or registered trademark of Quest Software, Inc. in the United States and/or other countries. Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries. Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates. QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation. Quantum and the Quantum logo are trademarks of Quantum Corporation, registered in the U.S.A. and other countries. Red Hat is a trademark of Red Hat, Inc., registered in the U.S. and other countries. Used under license. SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc. SPARC is a registered trademark of SPARC International, Inc. Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries. Unicode is a registered trademark of Unicode, Inc. in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN "AS-IS" BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The information contained in this document may contain references or cross-references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or services available in your country. Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time without notice. To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please teradata-books@lists.teradata.com. Any comments or materials (collectively referred to as "Feedback") sent to Teradata Corporation will be deemed non-confidential. Teradata Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback. Copyright by Teradata Corporation. All Rights Reserved.

3 Preface Purpose This is a reference book for the Teradata Database SQL Data Control Language (DCL) statements used to manage access to the database objects and data in the system. It describes the DCL statements that can be used to grant and revoke privileges and is intended to be used along with other Teradata Database books to manage access control and general system security. Related Documents For information about Teradata Database security, see Security Administration. For information about other types of Teradata Database SQL statements and their use, see SQL Data Definition Language and SQL Data Manipulation Language. For an introduction to s implementation of Teradata s implementation of SQL, see SQL Fundamentals. Audience This book is intended to be used by: Administrators that use SQL Data Control Language (DCL) statements to manage Teradata Database access control. Teradata technical personnel responsible for designing and maintaining Teradata Database. Supported Software Releases and Operating Systems This book supports Teradata Database Teradata Database 14.0 is supported on: SUSE Linux Enterprise Server (SLES)10 SLES 11 Note that SLES 11 will be supported after the initial release of Teradata Database Teradata Database client applications support other operating systems. SQL Data Control Language 3

4 Preface Changes To This Book Changes To This Book Release Teradata Database 14.0 June 2013 Teradata Database 14.0 January 2012 Teradata Database 14.0 November 2011 Description Corrected DROP, INDEX, and STATISTICS statement descriptions to indicate that you must now have the STATISTICS privilege to collect statistics. Removed the requirement that the EXECUTE FUNCTION be granted on all functions from EXECUTE FUNCTION Privilege on page 62. This is no longer a requirement. Added these sections: Teradata Database Privileges and Levels of Access Control on page 11 Object-Level Access Control on page 13 Row-Level Access Control on page 13 Teradata Row Level Security Privileges on page 66 CONSTRAINT ASSIGNMENT Privilege on page 66 CONSTRAINT DEFINITION Privilege on page 67 Object-Level Privileges on page 68 DML Restriction Override Privileges on page 68 Archive/Recovery Restriction Override Privileges on page 70 Example 20: Granting Row-Level Security OVERRIDE Privileges To Users and Roles on page 79 CONNECT THROUGH and Row-Level Security on page 90. Updated these sections: Supported Software Releases and Operating Systems on page 3 Database Privileges on page 10 Valid Privileges for Teradata Database SQL on page 10 GRANT (SQL Form) on page 31 Required Privileges on page 38 Restrictions on Granted Privileges on page 47 Logging Onto Teradata Database Using External Authentication and Explicit Mapping of a Directory User to Some Form of Teradata User on page 98 Removed caution statements from Chapter 2 about the potential for compromising your database when methods or functions are executed as part of the database software. This is no longer an issue. 4 SQL Data Control Language

5 Preface Additional Information Additional Information URL Description Use the Teradata Information Products Publishing Library site to: View or download a manual: 1 Under Online Publications, select General Search. 2 Enter your search criteria and click Search. Download a documentation CD-ROM: 1 Under Online Publications, select General Search. 2 In the Title or Keyword field, enter CD-ROM, and click Search. Order printed manuals: Under Print & CD Publications, select How to Order. tays.teradata.com/ developer.teradata.com/ The Teradata home page provides links to numerous sources of information about Teradata. Links include: Executive reports, white papers, case studies of customer experiences with Teradata, and thought leadership Technical information, solutions, and expert advice Press releases, mentions and media resources Teradata Customer Education designs, develops and delivers education that builds skills and capabilities for our customers, enabling them to maximize their Teradata investment. Use Your Service to access Orange Books, technical alerts, and knowledge repositories, view and join forums, and download software patches. Teradata Developer Exchange provides articles on using Teradata products, technical discussion forums, and code downloads. To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please teradatabooks@lists.teradata.com. Teradata Database Optional Features This book may include descriptions of the following optional Teradata Database features and products: Teradata Row Level Security Teradata Columnar SQL Data Control Language 5

6 Preface Teradata Database Optional Features Teradata Temporal Teradata Virtual Storage (VS) You may not use these features without the appropriate licenses. The fact that these features may be included in product media or downloads, or described in documentation that you receive, does not authorize you to use them without the appropriate licenses. Contact your Teradata sales representative to purchase and enable optional features. 6 SQL Data Control Language

7 Table of Contents Preface Purpose Audience Supported Software Releases and Operating Systems Changes To This Book Additional Information Teradata Database Optional Features Chapter 1: Teradata Database Privileges Database Privileges Teradata Database Access Control Support The Basic Types of User Privileges Non-User Privileges Chapter 2: Statement Syntax Types of DCL Statements GIVE GRANT GRANT (Monitor Form) GRANT (Role Form) GRANT (SQL Form) GRANT CONNECT THROUGH GRANT LOGON REVOKE REVOKE (Monitor Form) REVOKE (Role Form) REVOKE (SQL Form) REVOKE CONNECT THROUGH REVOKE LOGON SQL Data Control Language 7

8 Table of Contents Appendix A: Notation Conventions Syntax Diagram Conventions Character Shorthand Notation Used In This Book Glossary Index SQL Data Control Language

9 CHAPTER 1 Teradata Database Privileges This chapter provides an overview of the Teradata Database privileges and a summary of the types of access control (security) supported by the privileges. Terminology Although privileges are sometimes called access rights, permissions, or authorizations, this book uses the term privilege to ensure compliance with ANSI SQL:2008 specifications. Other Resources For information about initial setup of Teradata Database security features and general system security, see Security Administration. For an introduction to Teradata s implementation of SQL DCL, DML, and DDL, see SQL Fundamentals. SQL Data Control Language 9

10 Chapter 1: Teradata Database Privileges Database Privileges Database Privileges A database privilege is a permission to access or to manipulate a database object or data. Specific privileges are required for nearly everything that can be done in Teradata Database. Teradata Database privileges are used by administrators to control access to database objects and data, and to control the types of actions and activities available to users. The privileges can be used to control: Which users can access, create, modify, or delete specific database objects and data Which users can execute specific macros, stored procedures, and UDFs Which users can monitor system-wide activity Which users can grant privileges to other users The Teradata Database DCL requests are used grant and revoke the privileges that enable users to perform these actions and activities. See Types of DCL Statements on page 20 for a list of the types of DCL statements. Valid Privileges for Teradata Database SQL The privileges listed in the following table are all valid SQL privileges for Teradata Database. The term [(column_list)] following a privilege indicates a parenthetically enclosed set of optional comma-separated column names on which the privilege is to be granted to the specified user or role. Privilege ABORT SESSION ALTER EXTERNAL PROCEDURE ALTER FUNCTION ALTER PROCEDURE AUTHORIZATION CHECKPOINT CONSTRAINT ASSIGNMENT CONSTRAINT DEFINITION CREATE AUTHORIZATION CREATE DATABASE CREATE EXTERNAL PROCEDURE CREATE FUNCTION CREATE GLOP CREATE MACRO CREATE OWNER PROCEDURE CREATE PROCEDURE CREATE PROFILE CREATE ROLE CREATE TABLE CREATE TRIGGER CREATE USER CREATE VIEW CTCONTROL DATABASE DELETE DROP DROP AUTHORIZATION DROP DATABASE DROP FUNCTION DROP GLOP DROP MACRO DROP PROCEDURE DROP PROFILE DROP ROLE DROP TABLE DROP TRIGGER DROP USER DROP VIEW DUMP EXECUTE EXECUTE FUNCTION EXECUTE PROCEDURE FUNCTION GLOP GLOP MEMBER INDEX 10 SQL Data Control Language

11 Chapter 1: Teradata Database Privileges Database Privileges INSERT [(column_list)] INSERT [(ALL BUT] column_list)] MACRO MONITOR RESOURCE MONITOR SESSION NONTEMPORAL OVERRIDE DELETE CONSTRAINT OVERRIDE DUMP CONSTRAINT OVERRIDE INSERT CONSTRAINT OVERRIDE RESTORE CONSTRAINT Privilege OVERRIDE SELECT CONSTRAINT OVERRIDE UPDATE CONSTRAINT PROCEDURE REFERENCES [(column_list)] REFERENCES [(ALL BUT] column_list)] REPLCONTROL RESTORE SELECT [(column_list)] SELECT [(ALL BUT] column_list)] SET RESOURCE RATE SET SESSION RATE SHOW STATISTICS TABLE TRIGGER UDTMETHOD UDTTYPE UDTUSAGE UPDATE [(column_list)] UPDATE [(ALL BUT] column_list)] USER VIEW How Users Acquire Privileges Users acquire database privileges when: Directly An administrator uses an explicit DCL statement that: Grants the privilege to the user. Assigns a role that has the privilege to the user. Indirectly A user creates a database object. Temporarily A user has the privilege to execute a macro, stored procedure, or UDF, which allows database activity that the user cannot otherwise perform. Implicitly A user owns a database object. Teradata Database Privileges and Levels of Access Control Teradata Database privileges enable you to establish and maintain access control at various levels of granularity, including: System level Object level Database Table Row or column Other object types See Teradata Database Access Control Support on page 12 for information about Teradata Database access control support. SQL Data Control Language 11

12 Chapter 1: Teradata Database Privileges Teradata Database Access Control Support Teradata Database Access Control Support Teradata Database supports these basic types of access control: System-level access control Object-level access control Row-level access control (see Row-Level Access Control on page 13). System-Level Access Control Teradata Database privileges for system-level access control are granted by administrators to databases and users (they cannot be defined on any database object). The system-level privileges are: CONSTRAINT ASSIGNMENT CONSTRAINT DEFINITION CREATE ROLE CREATE PROFILE CTCONTROL DROP ROLE DROP PROFILE MONITOR ABORTSESSION MONRESOURCE MONSESSION SETRESRATE SETSESSRATE REPLCONTROL These privileges are used to control which users can: Assign row-level security constraints (CONSTRAINT ASSIGNMENT). Create, alter, and drop row-level security constraints (CONSTRAINT DEFINITION). Create roles and profiles (CREATE ROLE and CREATE PROFILE). Grant or revoke the CONNECT THROUGH privilege (CTCONTROL). Drop roles and profiles (DROP ROLE and DROP PROFILE). Monitor system-wide session activity and resource usage (MONRESOURCE and MONSESSION). Define and manage replication groups (REPLCONTROL). They are also used to control these system-level settings: Whether outstanding requests or ongoing transactions are automatically aborted (ABORTSESSION). 12 SQL Data Control Language

13 Chapter 1: Teradata Database Privileges Teradata Database Access Control Support The frequency at which processor resource usage data and session-level performance data is updated by the system (SETRESRATE and SETSESSRATE). These privileges are granted to users and databases using these SQL statements: GRANT (Monitor Form) on page 25 GRANT (SQL Form) on page 31 Object-Level Access Control Row-Level Access Control Teradata Database privileges for object-level access control are granted by administrators or by users that have the ability to create objects. These privileges can be granted: On database objects (databases, tables, columns, and other objects). To other users by the creator or owner of a database object. (For information about the privileges automatically granted by the system to object creators and object owners, see the Privileges Automatically Received section in Database Administration.) After the privileges are granted on the objects, users are able to perform the specific actions on the objects permitted by the privileges. The Teradata Row Level Security feature provides row-level access control. This feature is Teradata s implementation of Mandatory Access Control (MAC). In addition to supporting MAC, this feature provides a method for controlling access to row-level data that is simpler and easier to create and maintain than methods that utilize table-level or column-level access control. Attempting to control access to row-level data using table-level or column-level access control requires the creation and maintenance of numerous views that may be highly complex. Teradata Row Level Security is able to permit or deny a user the ability to execute one or more of the four basic SQL DML statement types against rows of a table (DELETE, INSERT, SELECT, and UPDATE). The Basic Teradata Row Level Security Elements Teradata Row Level Security utilizes a few basic elements to enable row-level access control. These basic elements are: Security constraints. Constraint functions (UDFs). Security credentials (row-level security constraint values). They work like required privileges do in other types of access control. In Teradata Database, administrators: Define security constraint functions. Create security constraints that can be defined on columns. Assign security credentials to permanent users or profiles. Define security constraint columns on tables that contain sensitive data. SQL Data Control Language 13

14 Chapter 1: Teradata Database Privileges Teradata Database Access Control Support Encode security credentials in sensitive data that you want to be available only to specific users (the credentials are encoded in row data). Note: All of these items are necessary to establish row-level access control to row-level data. A security constraint or security credential by itself is not sufficient. Where Information About Row-Level Security Elements is Stored Information about all of the current row-level security constraints, constraint assignments, and constraint functions is stored in these Data Dictionary tables: Information Names and values of row-level security constraints Constraint functions for row-level security constraints and statement actions Current assignment of row-level security constraint values Data Dictionary Table DBC.SecConstraints (names) DBC.ConstraintValues DBC.ConstraintFunctions DBC.AsgdSecConstraints What is Required to Access Data Protected by Row-Level Security When a user submits an SQL request, the system first checks the discretionary access control privileges defined on the target objects to determine if the action specified in the request is permitted. If the request is permitted for the objects, the system applies the security policy defined in the security constraint functions to all rows of the table, on a row-by-row basis. This is done to determine which rows can be accessed by the user. During the application of the policy, the system checks the security constraint values assigned to the constraint columns against the session constraint values for the user s session. If the set of constraint values for a particular row is permitted by the policy, the user is given access to that row. If the set of constraint values for a particular row is not permitted, the user is denied access to that row. A user may be granted access to some rows and not to other rows of the table. Note: Certain privileges can be used to temporarily enable users to bypass the row-level security policy. See DML Restriction Override Privileges on page 68 for information on these privileges. For More Information For Details about setting up row-level security. Details about the various row-level security constraints. See Security Administration SQL Data Definition Language Detailed Topics SQL Data Definition Language Syntax and Examples 14 SQL Data Control Language

15 Chapter 1: Teradata Database Privileges The Basic Types of User Privileges For Details about creating row-level security constraints. Details about how to write row-level security policy functions (UDFs). Details about the system tables that store data about row-level security constraints and constraint assignments. See Where Information About Row-Level Security Elements is Stored on page 14 for a list of these tables. See CREATE CONSTRAINT in SQL Data Definition Language Detailed Topics SQL External Routine Programming Data Dictionary The Basic Types of User Privileges Explicit User Privileges This section describes the basic types of Teradata Database user privileges and how to check user privileges. The basic types are: Explicit user privileges Implied and inherited user privileges (see Implied and Inherited User Privileges on page 16) See Checking User Privileges on page 17 for information on checking user privileges. All Teradata Database explicit privileges are those that are granted by administrators to users through the use of GIVE, GRANT, or REVOKE requests. These privileges can be applied at the database-level, table-level, and column-level. Many explicit privileges can be applied at more than one of these levels. The only explicit privileges that are restricted to a single level are: INDEX REFERENCES These two privileges can only be applied at the table-level. Note: To revoke these privileges from a user, you must revoke them explicitly. Specifying REVOKE ALL does not revoke them from a user. Minimizing Risks Associated With Explicit Privileges To minimize security risks, you should limit the number of users that have GIVE, GRANT, or REVOKE privileges. SQL Data Control Language 15

16 Chapter 1: Teradata Database Privileges The Basic Types of User Privileges Requirements for Administering Explicit User Privileges With few exceptions, users must have the following privileges to be able to use a GIVE, GRANT, or REVOKE request to administer explicit privileges: WITH GRANT OPTION (to grant explicit privileges to other users) WITH ADMIN OPTION (to grant explicit privileges to roles) To enable a user to grant one or more explicit privileges to other users, you must grant each privilege on a target object specified WITH GRANT OPTION (or WITH ADMIN OPTION for roles). The exceptions are: User DBC can administer privileges on all database objects, by default. Creators and owners of objects have explicit privileges on those objects by default, and can administer these privileges for other users. Creators and owners can also grant themselves any privileges that they do not acquire automatically on created or owned objects, and then administer those privileges for others. For More Information For information on syntax and the required privileges for a particular DCL statement, see Chapter 2: Statement Syntax. Implied and Inherited User Privileges You do not always need to explicitly grant a privilege to a user, or to a role in which the user is a member, because the user might already have the privilege as a result of other actions or conditions in the database. Teradata Database applies some privileges without the use of the forms of the GRANT request. Automatically, when you create a new user or database. The creator acquires certain privileges on the created user or database by default. A newly created user or database acquires certain privileges on itself by default. Implicitly, when a user owns Perm space. Space ownership includes certain implicit privileges on any object contained in the space and extends upward to all owners through the entire hierarchy of databases and users. From PUBLIC, the system level user that defines default privileges available to all users. You can grant additional privileges to PUBLIC that can then be applied to all users. You must complete special setup procedures to define database privileges for directory and proxy users. For More Information For information on various user types and associated privilege strategies, see Security Administration. 16 SQL Data Control Language

17 Chapter 1: Teradata Database Privileges Non-User Privileges Checking User Privileges Before you explicitly grant any privilege to a user or role, you can access Data Dictionary views to determine which privileges are already in effect. View AllRightsV AllRoleRights RoleMembersV Information it Contains The explicit and automatic privileges in effect for each user. The explicit privileges in effect for each role. The members (users) for each role. Teradata Database does not record privileges that derive from ownership, so they are not maintained in DBC.AllRightsV. For more information on Data Dictionary views, see Data Dictionary. Non-User Privileges In some cases, you might need to assign privileges to a non-user object, for example: You can grant privileges to a role based on the database access requirements of a specific group of users, and then grant role membership to each of the users individually. If you set up a separate Views database, you must grant the database privileges on the underlying tables of the views contained within that database. SQL Data Control Language 17

18 Chapter 1: Teradata Database Privileges Non-User Privileges 18 SQL Data Control Language

19 CHAPTER 2 Statement Syntax This chapter describes the SQL Data Control Language statements you can use to grant and revoke the privileges supported by Teradata Database. This information is provided for each statement: Description Syntax Compliance with ANSI SQL standard Required privileges (the privileges required to use the statement) Example of use SQL Data Control Language 19

20 Types of DCL Statements Types of DCL Statements Teradata Database DCL includes the following statement types. Type Description See GIVE GRANT (Monitor Form) Transfers ownership of an object, and all ownership privileges, from one user or database to another user or database. Grants system-wide performance monitoring privileges. GIVE on page 21 GRANT (Monitor Form) on page 25 GRANT (Role Form) Grants role membership to a user or role. GRANT (Role Form) on page 28 GRANT (SQL Form) GRANT CONNECT THROUGH GRANT LOGON REVOKE (Monitor Form) REVOKE (Role Form) REVOKE (SQL Form) REVOKE CONNECT THROUGH Grants selected or all privileges to a user or database on a specified database object. Grants the ability to connect as a proxy permanent or proxy application user through a specified trusted user. Grants privilege to log onto Teradata Database to a user and changes current system logon defaults. Revokes system-wide performance monitoring privileges. Revokes membership in a role from a user or role. Revokes selected or all privileges from a user or database on a specified database object. Revokes the ability to connect as a proxy permanent or proxy application user through a specified trusted user. GRANT (SQL Form) on page 31 GRANT CONNECT THROUGH on page 81 GRANT LOGON on page 96 REVOKE (Monitor Form) on page 102 REVOKE (Role Form) on page 106 REVOKE (SQL Form) on page 108 REVOKE CONNECT THROUGH on page 124 REVOKE LOGON Revokes the logon privilege from a user. REVOKE LOGON on page SQL Data Control Language

21 GIVE GIVE Transfers ownership of a database or user space to another user. Also transfers all databases and users owned by the transferred database or user. Syntax GIVE database_name TO recipient_name user_name ; FF07A025 where: Syntax Element... database_name user_name TO recipient_name Specifies... the name of the database or user whose ownership is being transferred. an introduction to the name of the recipient. the name of the new immediate owner for the transferred database or user. ANSI Compliance GIVE is a Teradata extension to the ANSI SQL:2008 standard. Other SQL dialects support similar non-ansi standard statements with names such as the following: TRANSFER OWNERSHIP Required Privileges You must have the DROP DATABASE privilege on the given object, and the CREATE DATABASE privilege on the recipient. The GIVE statement does not revoke any explicit privileges on the given database or user. No explicit privileges on the given database or user are granted to the new ownership hierarchy as a result of the GIVE statement, nor does the database or user being given receive any explicit privileges. The recipient of a GIVE statement cannot be owned by the given object; if A owns B, A cannot be given to B. SQL Data Control Language 21

22 GIVE Transfer of Space Allocation A transfer of ownership also transfers the permanent space allocated to the named database or user. This affects space allocation in the system as follows: The aggregate number of permanent space bytes available to the former owners (the owner who submits the GIVE statement plus the owners above this owner in the hierarchy) is reduced by the number of permanent space bytes in the transferred database. This includes total space allocated to the database, plus that of all databases and users owned by the transferred database. If the transferred database is dropped, then the number of bytes of permanent space allocated to the new immediate owner of the transferred database is increased by the number of bytes of permanent space in the transferred database. In addition, the aggregate number of bytes of permanent space available to owners above this owner in the hierarchy is increased by the number of bytes of permanent space that had been allocated to the transferred database. For example, consider the following hierarchy: DBC A (60) C (40) B (80) D (30) F (10) FF07A070 If ownership of database C is transferred to database D, the structure of the hierarchy changes as follows: DBC A (60) B (80) D (30) C (40) F (10) FF07A SQL Data Control Language

23 GIVE When database C is transferred, database F (which is owned by C) is also transferred. The number of permanent space bytes allocated to database A remains the same, but the aggregate number of permanent space bytes available to database A is reduced by 50 (the total number of permanent space bytes allocated to databases C and F). The number of bytes allocated to databases D and B remains the same. The available number of permanent space bytes, however, is increased by 50 (that is, if databases C and F were dropped, the bytes allocated to C and F are transferred to database D). A no longer has implicit privileges on C and F. B and D now have implicit privileges on C and F. There is a change in the explicit privileges held by any of the databases or users. For example, if A had granted itself explicit privileges on C, or F, or on objects they contain, then D would still have those explicit privileges after you had successfully submitted the GIVE statement. Example The following statement transfers ownership of the finance database from user administrator to user Chin. GIVE Finance TO Chin; SQL Data Control Language 23

24 GRANT GRANT GRANT establishes explicit privileges for one or more users, proxy users, databases, or roles. It has five forms that differ in function and in syntax: GRANT (Monitor Form) For performance monitoring of Teradata Database. See GRANT (Monitor Form) on page 25. GRANT (Role Form) For granting role membership to users and other roles. See GRANT (Role Form) on page 28. GRANT (SQL Form) For granting access to, creation of, or logging of, various Teradata database objects. See GRANT (SQL Form) on page 31. GRANT CONNECT THROUGH For granting the ability to connect as a proxy permanent or proxy application user through a trusted user. See GRANT CONNECT THROUGH on page 81. GRANT LOGON For granting system logon privileges. See GRANT LOGON on page 96. The SQL and MONITOR forms of GRANT are separate statements. To grant a user all privileges including MONITOR, you must perform both of the following requests: GRANT ALL PRIVILEGES ON object TO user WITH GRANT OPTION; GRANT MONITOR PRIVILEGES TO user WITH GRANT OPTION; GRANT MONITOR has no ON object clause. Because this statement allows its users to impact the entire system, it implies that the privilege is ON PUBLIC. 24 SQL Data Control Language

25 GRANT (Monitor Form) GRANT (Monitor Form) Syntax Grants system-wide performance monitoring privileges. GRANT MONITOR PRIVILEGES, TO A BUT NOT, monitor_privilege monitor_privilege, A ALL user_name WITH GRANT OPTION ; PUBLIC, role_name FF07B056 where: Syntax Element MONITOR PRIVILEGES MONITOR BUT NOT monitor_privilege ALL user_name PUBLIC WITH GRANT OPTION Specifies the named recipients are to receive all MONITOR-related privileges. MONITOR [PRIVILEGES] does not permit the user to grant the indicated privilege to others without the WITH GRANT OPTION being specified. the named recipients are to receive all of the grantable privileges except those specified after BUT NOT. If the ability to grant these privileges is to be included, the WITH GRANT OPTION must be specified explicitly. a valid monitoring privilege. See Monitor Privileges on page 27 for a list of the valid monitoring privileges. to grant the specified object privilege set to the named database or user and to every database or user owned by that database or user now and in the future. the name of a user or database to be granted the specified MONITOR privileges. You can specify up to 25 names. user_name must be the identifier of a user already defined to the system. that the privileges are to be inherited by all existing and future Teradata Database users. that the grantee receives privileges WITH GRANT OPTION. If this option is not specified, the grantee receives the privilege set without the grant option. SQL Data Control Language 25

26 GRANT (Monitor Form) ANSI Compliance Required Privileges The monitor form of GRANT is an extension to the ANSI SQL:2008 standard. You must have MONITOR privileges to use the monitor form of GRANT. These privileges should be granted only to those users who are cleared to monitor all applications on all sessions. There is no lower level of MONITOR privilege: its scope is always global. For example, the database administrator cannot grant user Addams the ability to do session-level monitoring of her applications only. Instead, the DBA would have to grant Addams the permission to do session-level monitoring of all applications by all sessions. To determine who is currently using the MONITOR partition, issue the following query: SELECT UserName, IFPNo FROM DBC.SessionInfoV WHERE partition = 'MONITOR'; The GRANT statement is used only to assign specific privileges. To transfer ownership of a database or user, see GIVE on page 21. GRANT (SQL Form) and GRANT (MONITOR Form) The SQL and MONITOR forms of GRANT are separate statements. To grant a user all privileges, including MONITOR, the grantor must perform both statements, as in the following example. GRANT ALL PRIVILEGES ON object TO user_name WITH GRANT OPTION; GRANT MONITOR PRIVILEGES TO user_name WITH GRANT OPTION; Never specify the WITH GRANT OPTION unless you want the recipient of a privilege to be able to grant it to others. ALL PRIVILEGES refers only to database-related privileges. MONITOR PRIVILEGES indicates all monitoring-related privileges. GRANT (SQL Form) Versus GRANT (MONITOR Form) A major difference between the syntax of the GRANT (SQL Form) and GRANT (MONITOR Form) statements is that GRANT (MONITOR Form) has no clause that specifies what the privilege has been granted on. Because GRANT (MONITOR form) allows a user to impact the entire system, the permissions are implicitly ON PUBLIC. 26 SQL Data Control Language

27 GRANT (Monitor Form) It is illegal to specify an ON object clause in any GRANT (MONITOR form) request. However, it is illegal not to specify an ON object clause in a GRANT (SQL Form) request. If you violate either of these restrictions, the system returns a failure response to the requestor. The two sets of GRANT privileges differ in function as well as in syntax. The GRANT (SQL Form) privilege set relates to controlling access to, and manipulation of, database objects, while the GRANT (MONITOR form) privilege set relates to monitoring system-wide performance. Privileges Granted Immediately Monitor Privileges GRANT MONITOR takes effect immediately when the grantee issues his next statement. It is unnecessary to log out to receive the monitor privilege just granted. You can specify any of the following privileges using the GRANT (Monitor Form) statement. Option ABORTSESSION MONRESOURCE MONSESSION SETRESRATE SETSESSRATE Description Aborts any outstanding request or ongoing transaction of one or more Teradata Database sessions and, optionally, logs off the sessions. Gathers information on the performance and availability of each PE and AMP. Gathers information about logged on sessions and overall system usage on a session-by-session basis. Sets the frequency at which processor resource usage data is updated in the system. Sets the frequency at which session-level performance data is updated in the system. For More Information See REVOKE (Monitor Form) on page 102 for information about revoking privileges granted by the Monitor form of GRANT. Security Logging of Access Attempts If you need to maintain a security log of access attempts, see BEGIN LOGGING in SQL Data Definition Language. SQL Data Control Language 27

28 GRANT (Role Form) GRANT (Role Form) Syntax Grants roles to users or other roles. Note: You cannot grant external roles with this GRANT statement. You can only grant individual privileges and database roles to external roles within Teradata Database. See Security Administration and Database Administration for details.,, GRANT role_name TO user_name role_name WITH ADMIN OPTION ; KZ01a008 where: Syntax Element role_name TO user_name role_name WITH ADMIN OPTION Specifies one or more comma-separated names of roles to grant to specified users or other roles. The system ignores duplicate role names. the names of role grantees. You can specify a maximum of 25 names per GRANT request. Grantees can be users or roles; however, a role cannot be granted to itself or to PUBLIC. GRANT does not produce an error if a specified role is already granted to a grantee. that the role grantees have the privilege to use DROP ROLE, GRANT, and REVOKE statements to administer the specified roles. A GRANT statement that does not include WITH ADMIN OPTION does not revoke a previously granted WITH ADMIN OPTION privilege from grantee. ANSI Compliance Required Privileges GRANT is ANSI SQL:2008-compliant. To grant a role, you must have the WITH ADMIN OPTION privilege on the role. The following users can grant a role to a user or other role: 28 SQL Data Control Language

29 GRANT (Role Form) User DBC. Restricted Privileges A user who has been granted the specified role WITH ADMIN OPTION. The creator of a role is automatically granted the specified role WITH ADMIN OPTION. A user who has an active role to which the specified role was granted WITH ADMIN OPTION. An active role can be a current role or a nested role of a current role. A grantor does not need to have any privilege, including WITH ADMIN OPTION, on the grantee to grant a privilege to it, whether the grantee is a role or a user. Roles cannot be granted on themselves or on PUBLIC, nor can they be granted any of the following privileges: CREATE PROFILE CREATE ROLE CREATE USER CTCONTROL DROP PROFILE DROP ROLE DROP USER REPLCONTROL About Roles Roles are used to define privileges on database objects for multiple users. A user who is assigned a role can access all the objects on which the role and its nested roles have privileges. Users can only be assigned a role that has been granted to them. You can grant a newly created role to a user or other role before the role has privileges on any database objects. An unlimited number of roles can be granted to a role or user. Role Hierarchy Roles can only be nested one level deep. Thus, a role that has a nested role cannot also be a nested role. This is a deviation from the ANSI SQL:2008 standard, which allows multiple nesting levels. SQL Data Control Language 29

30 GRANT (Role Form) Example The following statements create roles called services and sales: CREATE ROLE services; CREATE ROLE sales; To make sales a nested role of services, use the following GRANT statement: GRANT sales TO services; To grant the sales role to user marks, and give marks the privilege to add other members to sales, use the following GRANT statement: GRANT sales TO marks WITH ADMIN OPTION; For More Information For Details on granting privileges on database objects to roles and obtaining the CREATE ROLE system privilege Details on revoking privileges granted by the Role form of GRANT. Details on granting CONNECT THROUGH proxy connection privileges to a permanent or application user with a set of roles See GRANT (SQL Form) on page 31. REVOKE (Role Form) on page 106 GRANT CONNECT THROUGH on page 81 Details on assigning default roles to users CREATE USER in SQL Data Definition Language. MODIFY USER in SQL Data Definition Language. Details on changing the current role for a session SET ROLE in SQL Data Definition Language. 30 SQL Data Control Language

31 GRANT (SQL Form) GRANT (SQL Form) Syntax Grants one or more explicit privileges on a database, user, proxy logon user, table, hash index, join index, view, stored procedure, user-defined function, user-defined method, user-defined type, or macro to a role, group of roles, user, or group of users or databases. See Valid Privileges for Teradata Database SQL on page 10 for a list of all valid Teradata Database SQL privileges. See Temporal Table Support for information about granting the NONTEMPORAL privilege. GRANT ALL PRIVILEGES, privilege, ALL BUT privilege ON database_name user_name database_name.object_name user_name.object_name object_name PROCEDURE database_name. user_name. procedure_name A SPECIFIC FUNCTION specific_function_name database_name. user_name. function_name a FUNCTION database_name. user_name., TYPE a SYSUDTLIB. ( ) data type parameter_name UDT_name, role_privilege, profile_privilege CONSTRAINT ASSIGNMENT CONSTRAINT DEFINITION CTCONTROL REPLCONTROL 1101B753 SQL Data Control Language 31

32 GRANT (SQL Form) INTEGER SMALLINT BIGINT data type BYTEINT DATE TIME TIMESTAMP (fractional_seconds_precision) WITH TIMEZONE INTERVAL YEAR (precision) TO MONTH INTERVAL MONTH (precision) INTERVAL DAY (precision) TO HOUR MINUTE SECOND ( fractional_seconds_precision ) INTERVAL HOUR (precision) TO MINUTE SECOND ( fractional_seconds_precision ) INTERVAL MINUTE (precision) TO SECOND ( fractional_seconds_precision ) INTERVAL SECOND (precision ),fractional_seconds_precision PERIOD(DATE) PERIOD(TIME PERIOD(TIMESTAMP REAL DOUBLE PRECISION (precision) WITH TIMEZONE ) FLOAT DECIMAL NUMERIC ( integer ) ( integer ), integer A B 1101A SQL Data Control Language

33 ( Chapter 2: Statement Syntax GRANT (SQL Form) A B CHAR BYTE GRAPHIC VARCHAR CHAR VARYING VARBYTE VARGRAPHIC LONG VARCHAR LONG VARGRAPHIC ( integer ) ( integer ) BINARY LARGE OBJECT ( integer BLOB CHARACTER LARGE OBJECT CLOB G K M SYSUDTLIB. UDT_name ST_Geometry MBR 1101A536 where: Syntax Element ALL [PRIVILEGES] privilege Specifies that the specified user or database is to receive all privileges that can be granted on the specified object. GRANT ALL means that all implicit and explicit object privileges owned by the grantor WITH GRANT OPTION that pertain to the type of object, and only those privileges, are granted on the specified database object. To include the ability for the designated user to GRANT object privileges to other users or databases, specify WITH GRANT OPTION. Note: ALL cannot be granted to roles. An error is returned if the grantor has no privileges WITH GRANT OPTION on the object. You must use the monitor form of the GRANT statement to grant monitor privileges. See GRANT (Monitor Form) on page 25. one of the privileges listed under the topic ANSI Compliance on page 38 or one of the keywords for a privilege combination. See Granting Multiple Privileges With a Single Keyword on page 39 for a list of the valid combination privilege keywords and their meanings. Note that the INSERT, REFERENCES, SELECT, and UPDATE privileges have both table-level and column-level options. See REFERENCES on page 44. The DELETE privilege applies only to the DELETE DML statement, not to DELETE USER or DELETE DATABASE, which are granted by DROP USER and DROP DATABASE, respectively. See also Rules for privilege Keywords on page 41. However, for a full explanation of the privileges a specific statement requires, see its Authorization section in the appropriate volume of the SQL book set. SQL Data Control Language 33

34 GRANT (SQL Form) Syntax Element ALL BUT privilege database_name user_name database_name.object_ name user_name.object_name object_name [PROCEDURE] [database_name user_name] procedure_name Specifies the specified user is to receive all privileges that can be granted on the specified object except for those specified in the privilege list. As in ALL, only those object privileges owned by the grantor WITH GRANT OPTION are granted. ALL BUT is a Teradata extension to the ANSI SQL:2008 standard. Granting privileges on a database or user is a Teradata extension to the ANSI SQL:2008 standard. the name of the database or user on which the privilege set is granted. All objects contained by the specified database or user space are granted the specified privilege set. the name of the immediate owning database or user for the specified database object and the name of the database object (table, view, stored procedure, or macro) on which the privilege set is granted. Only the specified database object is granted the specified privilege set. the name of the immediately owning database or user and the name of the object (table, view, stored procedure, or macro) on which the privileges are to be granted. Only the named object is affected. the name of a database object (table, view, join index, function, stored procedure, or macro) on which the privileges set is granted. You should always qualify object names when granting privileges because Teradata Database checks for matching database names before checking for object names. If the object name is not qualified and the system finds a database with that name, then Teradata Database assumes it is a database name. If the object name is not qualified and no database having that name is found, then Teradata Database assumes it is an object within the current default database. If neither a database nor an object is found with the specified name, then Teradata Database aborts the request and returns an error to the requestor. that the object is a stored procedure. PROCEDURE is optional if the privilege being granted contains the PROCEDURE keyword. See Stored Procedure-Specific Privileges on page 60. You can qualify procedure_name by its containing database_name or user_name if necessary. You can grant the following privileges if you specify PROCEDURE. If you specify EXECUTE, you grant the EXECUTE PROCEDURE privilege. If you specify DROP, you grant the DROP PROCEDURE privilege. You must grant the ALTER EXTERNAL PROCEDURE and CREATE EXTERNAL PROCEDURE privileges explicitly. SPECIFIC FUNCTION [database_name user_name] specific_function_name the specific name of the function on which a privilege set is to be granted. The SPECIFIC FUNCTION keywords must be specified when a privilege is granted on an overloaded function. You can qualify specific_function_name by its containing database_name or user_name if necessary. 34 SQL Data Control Language