Fundamentals Of Access Rights In Teradata

(Part 1)

Prepared By: Smarak Das Employee Id: 391485

ACKNOWLEDGEMENT
This document is meant for associates with a brief understanding/knowledge of Teradata SQL. Through this document, I have explained the concepts associated with Access Rights. Access Rights is an integral dimension of any RDBMS and in Teradata, where Security is very stringently incorporated, Access Rights forms an integral part and hence, its understanding is crucial.

This document is not divided into multiple sections. Instead, after a brief introduction into the fundamentals of Access Rights, the different types of Access Rights are discussed along with user friendly examples. Appropriate reference points are also listed alongside each Access Rights type to properly distinguish each type from one another.

This document used the Metadata Tables in Teradata once in a while to illustrate a point. Metadata Tables are System Tables which stores System-related information. In Teradata, the System Tables are stored in the Database DBC.

Advanced topics related to Access Rights will be provided in the Part 2 of this document.

Finally, I have tried to polish off any discrepant errors that might have cropped in the document. Any factual error is deeply regretted and I shall be more than happy to remove them if pointed out.

ACCESS RIGHTS FUNDAMENTAL

Access Rights define the types of activities you can perform during a session. Access Rights are also called Privileges. Access Rights or Privileges control user activities such as creating, viewing, deleting, or tracking objects. Privileges also include the ability to grant privileges to other users in the database. A list of privileges has been provided below:

The above mentioned Access rights may be granted on: Users Views Columns of Tables Databases Macros Columns of Views Tables Stored Procedures

TYPES OF ACCESS RIGHTS: (a) Explicit (b) Automatic (c) Inherited (d) Implicit/Ownership BRIEF DEFINITION: (a) Explicit Privilege: A privilege that you explicitly grant with the GRANT statement. (b) Automatic Privilege: A privilege that is automatically granted by the system as though a GRANT statement was issued. (c) Inherited Privilege: A privilege that is assigned by means of a ROLE. Such privilege has not been explained in this document. (d) Implicit Privilege: A privilege for a user who directly or indirectly owns an object. Also called Ownership Privilege. The creator of an object is the user who submitted the CREATE statement. Every object has only one creator. An owner of an object is any database or user above the object in the database hierarchy. The immediate owner of a new object is the database space in which the new object resides.

In the above diagram, assuming that the user Security_Admin created the object Personnel under Human_Resources, then Security_Admin is the CREATOR and Human_Resources and SysDBA are OWNERs of Personnel.

AUTOMATIC PRIVILEGES
As mentioned earlier, Automatic Rights are A privilege that is automatically granted by the system as though a GRANT statement was issued. Now when a user creates a new object (User, Database, Table, View, Macro etc.), certain automatic privileges are granted to the Creator. Example, a user DBA_NPD creates an object say a Table named Table_SD, then the following privileges are granted automatically to the user DBA_NPD over the object Table_SD along with GRANT Authority: (a) Drop Table (b) Create Trigger (c) Drop Trigger (d) References (e) Delete (f) Insert (g) Restore (h) Index (i) Update (j) Dump (k) Select But, if the user DBA_NPD creates another user/database DBA_PD, then certain automatic rights are granted to both the Creator Entity DBA_NPD and the Created Entity DBA_PD. In other words, DBA_NPD has the following privileges on DBA_PD user/database or in layman terms, the user DBA_NPD can perform the following operations on DBA_PD user/database or in the space allocated for DBA_PD user/database : (a) Create/Drop Database (b) Create/Drop User (c) Create/Drop Macro (d) Create/Drop Table (e) Create/Drop Trigger (f) Create/Drop View (g) Drop Procedure (h) Drop Function (i) Dump (j) Restore (k) Execute (l) Insert (m)Update (n) Delete (o) Select

Whereas, the user/database DBA_PD has the following privileges on itself or in simple words, the user/database DBA_PD can perform the following actions in the space allocated to it: (a) Create/Drop Macro (b) Create/Drop Table (c) Create/Drop Trigger (d) Create/Drop View (e) Drop Procedure (f) Drop Function (g) Dump (h) Restore (i) Execute (j) Insert (k) Update (l) Delete (m)Select The Difference between the privileges granted to DBA_NPD and DBA_PD is: (a) Create/Drop Database (b) Create/Drop User

Another Example is attached below:

Automatic Privileges are inserted automatically by System in the DBC.AccessRights Metadata table. When creating an object, these Access Rights are granted automatically by the System and can be observed via Explain Plan as shown in the below figure:

NOTE:
(a) All the Privileges which are automatically granted are NOT the ONLY AVAILABLE Access Rights. There are other Privileges which are not automatically granted like Alter Function/Procedure, Create Procedure/Function, Execute Procedure/Function etc. These access rights must be granted explicitly via the GRANT command as we shall learn in Explicit Privileges. (b) All the Automatic Privileges can be dropped from a User/Database by the REVOKE command. Revoke command is used to remove privileges from a User/Database. (c) Automatic Privileges comes embedded with GRANT authority.

IMPLICIT/OWNERSHIP PRIVILEGES
Implicit rights belong to the owners of objects. Owners do not require rows in the AccessRights table to grant privileges on owned objects. Ownership rights cannot be revoked. An owner has the implicit right to GRANT privileges over any owned object. Using the above example,

The User/Database SysDBA and Human_Resources have Ownership Privilege or Implicit Privilege on the object Personnel. As is clear, by Owner, we mean all the owners, not just Immediate Owner. Certain definitive points about Implicit/Ownership Privileges are as follows: (a) An owner of a user/database is any user who owns the space from which that user or database is created. (b) An Owner can grant explicit privileges to other users, databases, roles etc. and can also grant the privileges WITH GRANT OPTION on the owned entity. (c) Implicit privileges are implied by ownership and no SQL statement needs to be submitted. (d) Owners DO NOT require rows in the DBC.AccessRights table to grant explicit privileges on owned objects. (e) Implicit privileges CANNOT BE revoked or refused. They cannot be taken away unless ownership is transferred or the owned entity is deleted or dropped.

NOTE:
(a) In the above figure, the user Security_Admin has AUTOMATIC Privilege on the object Personnel whereas the User/Database SysDBA and Human_Resources have Ownership/Implicit Privilege on the object Personnel. (b) GRANT Command and REVOKE Command has been explained in the Explicit Privilege section. (c) WITH GRANT OPTION means that the Access Rights via GRANT command will user/database can also GRANT privileges is not specified during GRANT command, NOT have the GRANT privilege. User/Database who is receiving the also have GRANT authority i.e. the to others. If WITH GRANT OPTION then the receiving user/database will

EXPLICIT PRIVILEGES
GRANT and REVOKE statements control explicit rights. The GRANT statement adds new rows to the DBC.AccessRights table. The REVOKE and DROP statements remove them from the DBC.AccessRights table. Now, to better understand Explicit Privileges, the bedrock of GRANT and REVOKE command must be studies.

(a)

GRANT COMMAND:

The GRANT command assigns one or more explicit privileges on a database, user, table, index, view, stored procedure, user-defined function, or macro to a role, group of roles, user, or group of users or databases. The GRANT command takes the following general form: GRANT <privilege-list> ON <object-name> TO <user-name> [WITH GRANT OPTION]

[ ] Indicates Optional

The recipient of an explicitly granted privilege may be:

Remember, to grant a privilege on an object to another user/database/role, the user who is submitting the GRANT statement can be: (a) Someone having the SAME privilege(s) on the SAME object(s) WITH GRANT OPTION authority. (b) An Owner of the object. (c) Someone granted the required privilege by any Owner of the object.

NOTE: The WITH GRANT OPTION confers on the recipient Grant Authority.
That recipient may then grant the access right to other users or databases.

In the given figure, the user/database Payroll_Admin has 4 objects under its ownership whereas Payroll_Users has 3 objects under its ownership.

If Payroll_Admin grants the SELECT privilege to user Personnel on the database Pay_DB: GRANT SELECT ON PAY_DB TO PAYROLL_USERS; The proper syntactical structure of GRANT command is:

NOTE:
(a) The PUBLIC option of the GRANT command allows privileges to be granted to all existing and future users. (b) The ALL username option of the GRANT command allows privileges to be granted to the named user and ALL current and future descendants. (c) Always remember, the WITH GRANT OPTION confers on the recipient Grant Authority. That recipient may then grant the access right to other users or databases.

(b) REVOKE COMMAND:

The REVOKE statement removes Automatic Rights inserted in the DBC.AccessRights table by a CREATE statement. It can also remove Explicit Rights inserted in the DBC.AccessRights table by the GRANT statement. Implicit Rights are governed by ownership and doesnt have rows in the DBC.AccessRights table and hence, cannot be revoked. The Syntax of REVOKE command:

To revoke a privilege, one must be: (a) Have the right to GRANT the Privilege. (b) Owner of the database object. (c) Someone granted the required privilege by any Owner of the object.

REVOKE Recipients: The REVOKE statement can remove privileges from one of the following: (a) Username: A specific named user(s). (b) PUBLIC: Every user in the DBC system. (c) ALL username: The named user and ALL descendants.

Using the same example,

Suppose, Payroll_Admin wishes to revoke the granted privilege as mentioned earlier:

REVOKE Select ON PAY_DB FROM Payroll_Users;

NOTE:
REVOKE is passive in that it: (a) Does not add rows to DBC.AccessRights. (b) Removes rows from the DBC.AccessRights table only if the privileges specified exist. (c) Does not cascade through the hierarchy unless you specify the ALL username option. (d) Is not automatically issued for privileges granted by a grantor dropped from the system. (e) GRANT OPTION FOR means that the privilege along with its GRANT permission is revoked.