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 TablesDatabases Macros Columns of ViewsTables Stored ProceduresTYPES 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 PRIVILEGESAs 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 PRIVILEGESImplicit 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 User/Database who is receiving the Access Rights via GRANT command will also have GRANT authority i.e. the user/database can also GRANT privileges to others. If ‘WITH GRANT OPTION’ is not specified during GRANT command, then the receiving user/database will NOT have the GRANT privilege.

EXPLICIT PRIVILEGESGRANT 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_DBTO 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 doesn’t 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 SelectON 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.