The Teradata Row Level Security feature provides a number of privileges that administrators can use to establish and maintain row-level security for the system. Some of the privileges are system-level privileges and some are object-level privileges.
Initially, only user DBC has row-level security privileges. Any other user must be explicitly granted row-level security privileges to be able to perform the following tasks:
- Create row-level security constraints.
- Assign row-level security constraint values (security credentials) to users and profiles.
- Define row-level security constraints on tables.
- Override (bypass) validation of the row-level security policies contained in the constraint functions applicable to target tables.
The basic types of row-level security privileges are:
- System-level privileges
- Object-level privileges (see Object-Level Privileges for Row-Level Security).
Although row-level security credentials are not privileges, they work like required privileges do in other types of access control. When you assign security credentials to users or profiles, you are essentially determining whether the users are able to access table rows that are protected by row-level security. (The security credential assigned to the users must match the security constraint values assigned to the row or rows they are attempting to access.) The exact type or types of access you permit is determined by the row-level security policy defined in the constraint function.