You are on page 1of 61

Teradata Row Level Security

By: Jim Browning


Date: February 3, 2012
Doc: 541-0009217A03
Release: Teradata 14.0

Abstract: Teradata Row Level Security (RLS), introduced in Teradata 14.0, provides for security

filtering of table rows based upon security attributes assigned to the requesting user and
associated attributes defined for the table. This Orange Book provides technical details for the
use of the feature and includes examples that can be used as a template for implementation.

This document is intended for use by Teradata Customers Only


In no case will you cause this document or its contents to be disseminated to any third party, reproduced or copied
by any means (in whole or in part) without Teradata's prior written consent. Please read the detailed copyright
notice on the following page.

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

Teradata Row Level Security

TERADATA CONFIDENTIAL
Copyright 2012 by Teradata Corporation.
All Rights Reserved.
This document, which includes the information contained herein,: (i) is the exclusive property of Teradata Corporation;
(ii) constitutes Teradata confidential information; (iii) may not be disclosed by you to third parties; (iv) may only be used
by you for the exclusive purpose of facilitating your internal Teradata-authorized use of the Teradata product(s)
described in this document to the extent that you have separately acquired a written license from Teradata for such
product(s); and (v) is provided to you solely on an "AS-IS" basis. In no case will you cause this document or its
contents to be disseminated to any third party, reproduced or copied by any means (in whole or in part) without
Teradata's prior written consent. Any copy of this document, or portion thereof, must include this notice, and all other
restrictive legends appearing in this document. Note that any product, process or technology described in this
document may be the subject of other intellectual property rights reserved by Teradata and are not licensed hereunder.
No license rights will be implied. Use, duplication, or disclosure by the United States government is subject to the
restrictions set forth in DFARS 252.227-7013(c)(1)(ii) and FAR 52.227-19. Other brand and product names used herein
are for identification purposes only and may be trademarks of their respective companies.\

Revision History
Revision/
Version
A01
A02

Author(s)

Date

Comments

Jim Browning
Jim Browning

1/18/12
2/03/12

Initial version for review


Update to address TRP review comments

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

Teradata Row Level Security

Table of Contents
1. INTRODUCTION ..................................................................................................................... 1
2. MANDATORY ACCESS CONTROL (MAC) .............................................................................. 4
3. CONSTRAINT ACCESS RIGHTS .......................................................................................... 7
3.1
CONSTRAINT DEFINITION .................................................................................... 7
3.2
CONSTRAINT ASSIGNMENT ................................................................................. 7
3.3
OVERRIDE CONSTRAINT ....................................................................................... 8
4. CONSTRAINT POLICY FUNCTIONS .................................................................................. 11
4.1
SELECT Policy Function .......................................................................................... 12
4.2
INSERT Policy Function ........................................................................................... 14
4.3
UPDATE Policy Function ......................................................................................... 15
4.4
DELETE Policy Function .......................................................................................... 18
5. CONSTRAINT OBJECTS ................................................................................................... 20
5.1
Hierarchical (Non-set) CONSTRAINT ..................................................................... 20
5.2
Non-hierarchical (Set) CONSTRAINT ..................................................................... 22
6. CONSTRAINT ASSIGNMENT ............................................................................................ 25
6.1
Assigning CONSTRAINT Names to Users ............................................................... 25
6.2
Assigning CONSTRAINT Names to Profiles ........................................................... 26
6.3
Assigning CONSTRAINT Objects to Tables ............................................................ 28
6.3.1
Base Tables ......................................................................................................... 28
6.3.2
Error Tables ........................................................................................................ 30
6.3.3
Save Tables ......................................................................................................... 31
7. SESSION CONSTRAINTS .................................................................................................. 32
8. CONSTRAINT AUDITING ................................................................................................. 34
9. LIMITS AND RESTRICTIONS ................................................................................................. 36
9.1
CONSTRAINT Object Limits ................................................................................... 36
9.2
User and Profile Limits .............................................................................................. 36
9.3
Session Limits ............................................................................................................ 36
9.4
Primary Indexes ......................................................................................................... 36
9.5
Primary and Foreign Keys ......................................................................................... 36
9.6
CHECK and UNIQUE Constraints............................................................................ 36
9.7
Partitioning Expressions ............................................................................................ 37
9.8
Compression .............................................................................................................. 37
9.9
Views ......................................................................................................................... 37
9.10 Join and Hash Indexes ............................................................................................... 37
9.11 Macros and Stored Procedures .................................................................................. 37
9.12 Triggers ...................................................................................................................... 37
9.13 Replication Groups .................................................................................................... 37
9.14 Statistics ..................................................................................................................... 37
9.15 Table Joins ................................................................................................................. 38
9.16 Compound Statements ............................................................................................... 38
9.17 ARCHIVE, COPY and RESTORE ........................................................................... 38
9.18 Aggregate and Ordered Analytical Functions ........................................................... 38
10.
DATA DICTIONARY........................................................................................................ 39
10.1 System Tables ............................................................................................................ 39
10.1.1 SecConstraints .................................................................................................... 39

ii Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

10.1.2 ConstraintFunctions ............................................................................................ 39


10.1.3 ConstraintValues ................................................................................................ 40
10.1.4 AsgdSecConstraints ............................................................................................ 40
10.1.5 TVM ................................................................................................................... 41
10.1.6 TVFields ............................................................................................................. 41
10.1.7 SessionTbl .......................................................................................................... 41
10.1.8 AccLogRuleTbl .................................................................................................. 42
10.1.9 AccLogTbl .......................................................................................................... 43
10.2 System Views ............................................................................................................ 43
10.2.1 SecConstraintsV[X] ............................................................................................ 43
10.2.2 ConstraintFunctionsV ......................................................................................... 44
10.2.3 ConstraintValuesV ............................................................................................. 44
10.2.4 UsrAsgdSecConstraintsV[X] ............................................................................. 45
10.2.5 ProfileAsgdSecConstraintsV[X] ........................................................................ 45
10.2.6 ColumnsV[X] ..................................................................................................... 45
10.2.7 AccLogRulesV ................................................................................................... 46
10.2.8 AccessLogV ....................................................................................................... 46
11.
ERROR MESSAGES ......................................................................................................... 47
12.
FUTURE ENHANCEMENTS .............................................................................................. 54
13.
REFERENCES .................................................................................................................. 55

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

iii

Teradata Row Level Security

1. Introduction
Row-level security refers to the filtering of access to rows within a database table based upon
the content of one or more columns within a row and attributes associated with the user or
application accessing the table. Use of row-level security allows for data that is maintained in
a common set of tables to be accessed by different constituencies where each constituency
may be allowed to access only a subset of the data based upon some security requirement or
policy.
Historically, row-level security is implemented within Teradata Databases through the use of
views where row-level access rules are encoded using SQL logic within the view definition.
These can be simple rules that simply filter data based on a predicate evaluation or more
complex rules that may include a join to one or more security tables that may supply attributes
of the users or applications to be used for the evaluation.
Following is an example of a row-level security enforcing view built on an Employee table to
filter row access by department. This view definition includes a join to a Security table that is
used to define the department as an attribute of the users that access the table.

Teradata Row Level Security provides an alternative method for implementing row-level
security. It is primarily designed to meet requirements for Mandatory Access Control (as
discussed in Chapter 2) although the design allows for extensibility to meet other row-level
security requirements particularly those that may be similar in nature to Mandatory Access
Control. Teradata Row Level Security is not a replacement for view-based approaches as
these may often be better suited for many applications where the ability to encode filtering

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

Teradata Row Level Security

rules in SQL and use information from different tables is required. However, Teradata Row
Level Security does address two specific weaknesses common to view-based approaches:
1) View-based row-level security only secures the underlying data for accesses
through the views. Any other access to the underlying base tables effectively
bypasses the row-level security policy. Teradata Row Level Security is applied to
the base tables and the row-level security policy is enforced on any access to the
base tables regardless of how the tables are being accessed.
2) View-based row-level security works very well to filter access for SELECT
operations but generally cannot be used to filter access for INSERT, UPDATE and
DELETE operations. Teradata Row Level Security provides the capability to filter
access for SELECT, INSERT, UPDATE, and DELETE operations.

Teradata Row Level Security is based on the use of user-defined security policy functions that
are assigned to database tables and which execute to filter access to rows whenever data in the
tables is queried or updated. A new type of database object called a CONSTRAINT object is
introduced to identify the security policy functions and the attributes (indicated by
name:value pairs) to be evaluated by those functions for row-level security filtering. New
access rights are supported to restrict the management of the row-level security policies to one
or more designated database security administrators. With these rights, a database security
administrator can perform the following functions:
Create and manage CONSTRAINT objects
Assign CONSTRAINT names to users and profiles
Assign CONSTRAINT objects to tables

The basic tasks for configuring and implementing Teradata Row Level Security can be
described as follows:
Grant rights to create and managed CONSTRAINT objects and assignments to an
appropriate security administrator user
Develop and create security policy functions (as user-defined functions) to enforce the
desired row-level security filtering
Create CONSTRAINT objects to define valid name:value pairs and policy functions
Assign CONSTRAINT names to users and profiles as required
Assign CONSTRAINT objects to tables as required
Grant OVERRIDE CONSTRAINT rights to appropriate users if required for
populating CONSTRAINT object columns
Populate CONSTRAINT object columns with valid values as defined in the associated
CONSTRAINT objects
The following diagram illustrates the logical relationship between various database objects
and operations as used by Teradata Row Level Security.

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

Chapters 3-8 of this book provide details and examples of the use of Teradata Row Level
Security.
Chapter 3 discusses access rights for creating and managing row-level security
objects and policies
Chapter 4 discusses the creation and use of policy functions
Chapter 5 describes the two types of CONSTRAINT objects
Chapter 6 discusses the assignment and use of CONSTRAINT objects with users,
profiles, and tables
Chapter 7 discusses how CONSTRAINT value assignments are used a part of a
users session state
Chapter 8 discusses security auditing of row-level security operations

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

Teradata Row Level Security

2. Mandatory Access Control (MAC)


The Teradata Database implements a typical Discretionary Access Control (DAC) security
model whereby access to database objects is allowed at the discretion of the objects owner
that is, the owner of an object may grant access other users and roles as desired.
As defined by the Trusted Computer Security Evaluation Criteria (DoD 5200.28-STD),
Mandatory Access Control (MAC) is a security model whereby access to database objects is
restricted based on the sensitivity of the data contained within the objects and the formal
authorization level of users attempting to access the data. MAC is a common requirement for
securing highly sensitive data within Government agencies worldwide.
Common implementations of MAC within relational database management systems are based
upon the Bell-LaPadula Model and the subsequent Biba Integrity Model. The basic model
defines a relationship between objects (data) and subjects (users and applications). Data
within an object (i.e., rows within a table) may be assigned a classification to indicate the
sensitivity of the data. For example, a typical Government organization might classify data
using hierarchical levels such as Top Secret, Secret, Confidential, and Unclassified. Subjects
are subsequently assigned a similar clearance which determines the levels of data for which
access will be allowed.
The definition of the classifications and clearances are often described as a security label. A
security label generally includes two components: a required hierarchical component and an
optional non-hierarchical set of compartments. The hierarchical component is used to indicate
the sensitivity of the data while the non-hierarchical component may be used to identify and
restrict access by categories or groups. Labels are assigned to objects and subjects and
subsequently used to enforce access rules. The following diagram illustrates an example of
the typical use of labels within a relational database system.

With Teradata Row Level Security, the required hierarchical classification component of a
security label can be defined and managed using a hierarchical (non-set) CONSTRAINT
object as described in Chapter 5.1. Similarly, the optional non-hierarchical compartment
component of a security label can be defined and managed using a non-hierarchical (set)
CONSTRAINT object as described in Chapter 5.2.
As initially described by the Bell-LaPadula Model, MAC enforces a no-read-up, no-writedown set of rules to restrict access to labeled data. These rules are defined as follows:

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

no-read-up:

A subject is allowed read access to an object if and only if the


subjects label dominates the objects label. That is, the subjects
classification must be greater than or equal to the objects
classification. If a compartment component is defined, then the
subjects compartment set must include the compartment set of the
object.

no-write-down: A subject is allowed write access to an object if and only if the


objects label dominates the subjects label. That is, the objects
classification must be greater than or equal to the subjects
classification. If a compartment component is defined, then the
objects compartment set must include the compartment set of the
subject.
Enforcement of MAC policy does not replace the standard DAC policy. The Teradata
Database will first enforce the DAC policy (ensuring that the user has appropriate access
rights on the table) before enforcing the MAC policy. The following diagram depicts the
process flow used to determine access to data and filter access to rows based upon the policy.

Throughout this book examples are provided for writing and defining policy functions,
creating and managing CONSTRAINT objects, and assigning CONSTRAINT objects and
names to users, profiles, and tables. Collectively, these examples serve to demonstrate the
construction and assignment of a MAC security label with both a classification component

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

Teradata Row Level Security

and a compartment component and an implementation and enforcement of the standard MAC
no-read-up, no-write-down access policy.

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

3. CONSTRAINT Access Rights


Teradata Row Level Security introduces several new access rights which are required for
administration and management of CONSTRAINT objects, assignment of CONSTRAINT
names to users and profiles, assignment of CONSTRAINT objects to database tables, and for
effective management of RLS-protected tables.
3.1 CONSTRAINT DEFINITION
The CONSTRAINT DEFINITION access right is a system-level privilege that is required in
order to CREATE, ALTER, or DROP CONSTRAINT objects. This right also allows for
SHOW CONSTRAINT requests.
CONSTRAINT DEFINITION is initially granted only to user DBC, WITH GRANT
OPTION, and must be explicitly granted as required to one or more security administrators
tasked with the management of CONSTRAINT objects. As a system-level privilege, this
right can only be granted to users and roles. It cannot be granted to a database nor can it be
granted to PUBLIC.
GRANT and REVOKE (SQL Form) statements are used to grant and revoke the
CONSTRAINT DEFINITION access right. The syntax for these statements is defined as
follows:

3.2 CONSTRAINT ASSIGNMENT


The CONSTRAINT ASSIGNMENT access right is a system-level privilege that is required in
order to assign CONSTRAINT names to users and profiles and assign CONSTRAINT objects
to database tables. This right also allows for SHOW CONSTRAINT requests as well as
permits the grantee to grant OVERRIDE CONSTRAINT rights.
CONSTRAINT ASSIGNMENT is initially granted only to user DBC, WITH GRANT
OPTION, and must be explicitly granted as required to one or more security administrators
tasked with the assignment of CONSTRAINT objects. As a system-level privilege, this right

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

Teradata Row Level Security

can only be granted to users and roles. It cannot be granted to a database nor can it be granted
to PUBLIC.
GRANT and REVOKE (SQL Form) statements are used to grant and revoke the
CONSTRAINT ASSIGNMENT access right. The syntax for these statements is defined as
follows:

3.3 OVERRIDE CONSTRAINT


The OVERRIDE CONSTRAINT access rights provide a mechanism to bypass row-level
security policy filtering for specific SELECT, INSERT, UPDATE, DELETE, DUMP
(ARCHIVE), and RESTORE requests. Typically, these rights would be granted to utility
users to facilitate efficient load, export, archive, and restore of RLS-protected tables.
OVERRIDE CONSTRAINT access rights can be granted at the database (user), table, or
column level. A user must have the CONSTRAINT ASSIGNMENT privilege in order to
grant or revoke OVERRIDE CONSTRAINT rights.
OVERRIDE CONSTRAINT access rights affect SQL and utility requests as follows:
OVERRIDE SELECT CONSTRAINT - When this right is granted on one or more
specific CONSTRAINT columns of a RLS-protected table, the security policy
enforced by the SELECT policy functions associated with those CONSTRAINT
columns is bypassed. When this right is granted on a RLS-protected table then the
security policy enforced by the SELECT policy functions associated with all
CONSTRAINT columns is bypassed.
OVERRIDE INSERT CONSTRAINT - When this right is granted on one or more
specific CONSTRAINT columns of a RLS-protected table, the security policy in the
INSERT policy functions associated with those CONSTRAINT columns is bypassed
and the INSERT request must include the values for the associated CONSTRAINT
columns. When this right is granted on a RLS-protected table then the security policy

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

enforced by the INSERT policy functions associated with all CONSTRAINT columns
is bypassed and the INSERT request must include the values for all associated
CONSTRAINT columns.
OVERRIDE UPDATE CONSTRAINT - When this right is granted on one or more
specific CONSTRAINT columns of a RLS-protected table, the security policy
enforced by the UPDATE policy functions associated with those CONSTRAINT
columns is bypassed. When this right is granted on a RLS-protected table then the
security policy enforced by the UPDATE policy functions associated with all
CONSTRAINT columns is bypassed. When a user with the OVERRIDE UPDATE
CONSTRAINT right submits an UPDATE statement, the SET clause does not need to
include the values for the associated CONSTRAINT columns unless those columns
are being updated.
OVERRIDE DELETE CONSTRAINT - When this right is granted on one or more
specific CONSTRAINT columns of a RLS-protected table, the security policy
enforced by the DELETE policy functions associated with those CONSTRAINT
columns is bypassed. When this right is granted on a RLS-protected table then the
security policy enforced by the DELETE policy functions associated with all
CONSTRAINT columns is bypassed.
OVERRIDE DUMP CONSTRAINT - When this right is granted on a RLSprotected table (or database containing the table), DUMP (ARCHIVE) requests are
allowed for the table.
OVERRIDE RESTORE CONSTRAINT - When this right is granted on a RLSprotected table (or database containing the table), COPY and RESTORE requests are
allowed for the table.
GRANT and REVOKE (SQL Form) statements are used to grant and revoke OVERRIDE
CONSTRAINT access rights. The syntax for these statements is defined as follows:

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

Teradata Row Level Security

10

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

4. CONSTRAINT Policy Functions


With Teradata Row Level Security, filtering of rows within tables is done using policy
functions implemented as scalar user-defined functions (UDFs). Functions can be
implemented to enforce security policy for SELECT, INSERT, UPDATE and DELETE
requests and are specified as part of the CONSTRAINT object definition. If a policy function
for a specific type of request is not specified as part of a CONSTRAINT associated with a
RLS-protected table, then that request will not be permitted unless the user has been granted
the appropriate OVERRIDE CONSTRAINT access right. Similarly, if a user has been
granted appropriate OVERRIDE CONSTRAINT access rights, then policy functions are not
invoked for operations performed by that user on the RLS-protected table.
Since the policy functions are user-defined, they can be designed and coded to enforce
different security policies as required. Policy functions for SELECT and UPDATE requests
evaluate the CONSTRAINT values for the user/session and each affected row within the table
to determine whether or not the requests will be applied to the row. Policy functions for
INSERT requests evaluate the CONSTRAINT values for the user/session to determine
whether or not the requests will be applied to the row. Policy functions for DELETE requests
evaluate the CONSTRAINT values for each affected row within the table to determine
whether or not the requests will be applied to the row. Policy functions for INSERT and
UPDATE requests further return the value to be stored in the CONSTRAINT column for each
row for which the operation is applied.
Policy function UDFs must be created in the SYSLIB database in order to be specified as part
of a CONSTRAINT object. UDFs specified as part of a CONSTRAINT object may be
altered or replaced as required. However, such UDFs cannot be dropped while specified as
part of a CONSTRAINT object.
Policy function UDFs cannot be overloaded. Function arguments, return values, and
associated data types are determined based upon the type of SQL operation the function
protects and the data type specified in the associated CONSTRAINT object.
Policy function UDFs must be implemented as C language scalar functions.
When creating a policy function, specific naming conventions for parameter names used by
the function must be followed:
CURRENT_SESSION If the policy function evaluates a session CONSTRAINT
value, then the corresponding parameter name must be specified as
CURRENT_SESSION with the same data type as defined for the associated
CONSTRAINT object. The value passed as the input argument to the function is the
value currently set for the session.
INPUT_ROW If the policy function evaluates a row CONSTRAINT value, then the
corresponding parameter name must be specified as INPUT_ROW with the same data
type as defined for the associated CONSTRAINT object. The value passed as the

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

11

Teradata Row Level Security

input argument to the function is the value from the corresponding CONSTRAINT
column of the row which is being evaluated.
If a CONSTRAINT object definition allows for NULL values, then the specified policy
function UDFs must be coded and created as PARAMETER STYLE SQL. If NULL values
are not allowed then the policy function UDFs must be coded and created as PARAMETER
STYLE TD_GENERAL.
Users accessing tables that are assigned CONSTRAINT objects do not need to be explicitly
granted EXECUTE FUNCTION rights on the associated policy functions. The Parser will
automatically add calls to the policy function UDFs as predicates for DML statements. Use
of the policy functions can be observed in the EXPLAIN output for queries accessing RLSprotected tables.
Once the policy functions have been fully tested then consideration should be given to
altering the functions to execute NOT PROTECTED. Row filtering by UDFs executing in
protected mode will likely incur unacceptable performance overhead.
Refer to the Teradata Database SQL External Routine Programming and Teradata Database
SQL Data Definition Language reference manuals for detailed information about writing and
creating user-defined functions.
4.1 SELECT Policy Function
The SELECT policy function has three input arguments. The first argument is a pointer to the
value currently set for the session and the second argument is a pointer to the value from the
corresponding CONSTRAINT column of the row which is being evaluated. The third
argument is a pointer to a value of type char(1) which is used to return the result of the
function. The function evaluates the first two input argument values and then returns in the
third argument a non-NULL T to indicate that access to the associated row is allowed, or F
to indicate that access to the associated row is not allowed and that the row is to be excluded.
Following is a C language example of a SELECT policy function for a hierarchical (non-set)
CONSTRAINT that implements the MAC no-read-up policy.
// udf_SelectClassification.c
#define SQL_TEXT Latin_Text
#include <sys/types.h>
#include "sqltypes_td.h"
void SelectClassification(short int *UserClearance,
short int *RowClassification,
char *AccessAllowed)
{
// Enforce no-read-up policy
// User's clearance must dominate the row classification
if (*UserClearance >= *RowClassification)
// SELECT is allowed
*AccessAllowed = 'T';
else
// SELECT is not allowed
*AccessAllowed = 'F';

12

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

return;
}

Following is the DDL that would be used to create the above example SELECT policy
function. Note specifically the use of the required CURRENT_SESSION and INPUT_ROW
parameter name constructs.
REPLACE FUNCTION SYSLIB.SelectClassification
(CURRENT_SESSION smallint, INPUT_ROW smallint)
RETURNS char(1)
SPECIFIC SYSLIB.SelectClassification
LANGUAGE C
DETERMINSTIC
NO SQL
EXTERNAL NAME 'cs!SelectClassification!udf_SelectClassification.c'
PARAMETER STYLE TD_GENERAL;

Following is a C language example of a SELECT policy function for a non-hierarchical (set)


CONSTRAINT that implements the MAC no-read-up policy.
// udf_SelectCompartment.c
#define SQL_TEXT Latin_Text
#include <sys/types.h>
#include "sqltypes_td.h"
typedef unsigned char byte;
void SelectCompartment(byte *UserCompartments,
byte *RowCompartments,
char *AccessAllowed,
int *UserCompartments_i,
int *RowCompartments_i,
int *AccessAllowed_i)
{
register i;
*AccessAllowed_i = 0;

// Never returns NULL result

// Enforce no-read-up policy


// User's compartments must dominate the row compartments
// If row compartments are NULL, then SELECT is allowed
if (*RowCompartments_i == -1) {
*AccessAllowed = 'T';
return;
}
// Row compartments are
// If user compartments
if (*UserCompartments_i
*AccessAllowed =
return;
}

not NULL
are NULL, then SELECT is not allowed
== -1) {
'F';

// User and row compartments are not NULL


// Check for user compartments dominating row compartments
for (i = 0; i < 8; i++) {
if ((RowCompartments[i] ^ UserCompartments[i]) & RowCompartments[i]) {
// SELECT is not allowed
*AccessAllowed = 'F';
return;
}
}

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

13

Teradata Row Level Security

// SELECT is allowed
*AccessAllowed = 'T';
return;
}

Following is the DDL that would be used to create the above example SELECT policy
function. Note specifically the use of the required CURRENT_SESSION and INPUT_ROW
parameter name constructs.
REPLACE FUNCTION SYSLIB.SelectCompartment
(CURRENT_SESSION byte(8), INPUT_ROW byte(8))
RETURNS char(1)
SPECIFIC SYSLIB.SelectCompartment
LANGUAGE C
DETERMINSTIC
NO SQL
EXTERNAL NAME 'cs!SelectCompartment!udf_SelectCompartment.c'
PARAMETER STYLE SQL;

4.2 INSERT Policy Function


The INSERT policy function has two input arguments the first of which is a pointer to the
value currently set for the session. The second input argument is a pointer to a value of the
type defined by the associated CONSTRAINT object (smallint or byte(n)) which is used to
return the result of the function. The function evaluates the first input argument value and
then returns a value to be inserted into the corresponding CONSTRAINT column.
Following is a C language example of an INSERT policy function for a hierarchical (non-set)
CONSTRAINT that implements the MAC policy.
// udf_InsertClassification.c
#define SQL_TEXT Latin_Text
#include <sys/types.h>
#include "sqltypes_td.h"
void InsertClassification(short int *UserClearance,
short int *RowClassification)
{
// Policy is to set rows level to the user clearance
// specified for the session
*RowClassification = *UserClearance;
return;
}

Following is the DDL that would be used to create the above example INSERT policy
function. Note specifically the use of the required CURRENT_SESSION parameter name
construct.
REPLACE FUNCTION SYSLIB.InsertClassification
(CURRENT_SESSION smallint)
RETURNS smallint
SPECIFIC SYSLIB.InsertClassification
LANGUAGE C
DETERMINSTIC
NO SQL

14

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

EXTERNAL NAME 'cs!InsertClassification!udf_InsertClassification.c'


PARAMETER STYLE TD_GENERAL;

Following is a C language example of an INSERT policy function for a non-hierarchical (set)


CONSTRAINT that implements the MAC policy.
// udf_InsertCompartment.c
#define SQL_TEXT Latin_Text
#include <sys/types.h>
#include "sqltypes_td.h"
typedef unsigned char byte;
void InsertCompartment(byte *UserCompartments,
byte *NewRowCompartments,
int *UserCompartments_i,
int *NewRowCompartments_i)
{
register i;
// Policy is to set row compartments to the user compartments
// specified for the session
// If user/session compartments are NULL, then return NULL
if (*UserCompartments_i == -1) {
*NewRowCompartments_i = -1;
return;
}
// User/session compartments are not NULL
for (i = 0; i < 8; i++)
NewRowCompartments[i] = UserCompartments[i];
*NewRowCompartments_i = 0;
return;
}

Following is the DDL that would be used to create the above example INSERT policy
function. Note specifically the use of the required CURRENT_SESSION parameter name
construct.
REPLACE FUNCTION SYSLIB.InsertCompartment
(CURRENT_SESSION byte(8))
RETURNS byte(8)
SPECIFIC SYSLIB.InsertCompartment
LANGUAGE C
DETERMINSTIC
NO SQL
EXTERNAL NAME 'cs!InsertCompartment!udf_InsertCompartment.c'
PARAMETER STYLE SQL;

4.3 UPDATE Policy Function


The UPDATE policy function has three input arguments. The first argument is a pointer to
the value currently set for the session and the second argument is a pointer to the value from
the corresponding CONSTRAINT column of the row which is being evaluated. The third
argument is a pointer to value of the type defined by the associated CONSTRAINT object
(smallint or byte(n)) which is used to return the result of the function. The function evaluates
the first two input argument values and then returns in the third argument a value to be

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

15

Teradata Row Level Security

updated in the corresponding CONSTRAINT column. A value of 0 returned in the third


argument indicates that the row will not be considered for the UPDATE request.
Following is a C language example of an UPDATE policy function for a hierarchical (nonset) CONSTRAINT that implements the MAC no-write-down policy.
// udf_UpdateClassification.c
#define SQL_TEXT Latin_Text
#include <sys/types.h>
#include "sqltypes_td.h"
void UpdateClassification(short int *UserClearance,
short int *RowClassification,
short int *NewRowClassification)
{
// Enforce no-write-down policy
// Row classification must dominate the user's clearance
// User's clearance must be equal to or greater than the
// row classification to allow the update.
if (*UserClearance >= *RowClassification)
*NewRowClassification = *UserClearance;
else
// Update not allowed
*NewRowClassification = 0;
return;
}

Following is the DDL that would be used to create the above example UPDATE policy
function. Note specifically the use of the required CURRENT_SESSION and INPUT_ROW
parameter name constructs.
REPLACE FUNCTION SYSLIB.UpdateClassification
(CURRENT_SESSION smallint, INPUT_ROW smallint)
RETURNS smallint
SPECIFIC SYSLIB.UpdateClassification
LANGUAGE C
DETERMINSTIC
NO SQL
EXTERNAL NAME 'cs!UpdatetClassification!udf_UpdateClassification.c'
PARAMETER STYLE TD_GENERAL;

Following is a C language example of an UPDATE policy function for a non-hierarchical


(set) CONSTRAINT that implements the MAC no-write-down policy.
// udf_UpdateCompartment.c
#define SQL_TEXT Latin_Text
#include <sys/types.h>
#include "sqltypes_td.h"
typedef unsigned char byte;
void UpdateCompartment(byte *UserCompartments,
byte *RowCompartments,
byte *NewRowCompartments,
int *UserCompartments_i,
int *RowCompartments_i,
int *NewRowCompartments_i)
{

16

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

register i;
// Enforce no-write-down policy
// Row compartments must dominate the user's compartments
// If user/session and row compartments are NULL, then
// UPDATE is allowed with NULL
if (*UserCompartments_i == -1) {
if (*RowCompartments_i == -1) {
*NewRowCompartments_i = -1; // SET row compartments to NULL
return;
} else {
// User/session compartments are NULL but row compartments are not // UPDATE is not allowed
for (i = 0; i < 8; i++)
NewRowCompartments[i] = 0;
*NewRowCompartments_i = 0;
return;
}
}
// If row compartments are NULL, then
// UPDATE is allowed with user/session compartments
if (*RowCompartments_i == -1) {
for (i = 0; i < 8; i++)
NewRowCompartments[i] = UserCompartments[i];
*NewRowCompartments_i = 0;
return;
}
// Check for row compartments dominating user/session compartments
for (i = 0; i < 8; i++) {
if ((UserCompartments[i] & RowCompartments[i]) != RowCompartments[i]) {
// UPDATE is not allowed
for (i = 0; i < 8; i++)
NewRowCompartments[i] = 0;
*NewRowCompartments_i = 0;
return;
}
}
// UPDATE is allowed with inclusive user/session and row compartments
for (i = 0; i < 8; i++)
NewRowCompartments[i] = UserCompartments[i] | RowCompartments[i];
*NewRowCompartments_i = 0;
return;
}

Following is the DDL that would be used to create the above example UPDATE policy
function. Note specifically the use of the required CURRENT_SESSION and INPUT_ROW
parameter name constructs.
REPLACE FUNCTION SYSLIB.UpdateCompartment
(CURRENT_SESSION byte(8), INPUT_ROW byte(8))
RETURNS byte(8)
SPECIFIC SYSLIB.UpdateCompartment
LANGUAGE C
DETERMINSTIC
NO SQL
EXTERNAL NAME 'cs!UpdateCompartment!udf_UpdateCompartment.c'
PARAMETER STYLE SQL;

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

17

Teradata Row Level Security

4.4 DELETE Policy Function


The DELETE policy function has two input arguments the first of which is a pointer to the
value from the corresponding CONSTRAINT column of the row which is being evaluated.
The second argument is a pointer to a value of type char(1) which is used to return the result
of the function. The function evaluates the first input argument value and then returns in the
second argument a non-NULL T to indicate that the DELETE of the associated row is
allowed, or F to indicate that the DELETE of the associated row is not allowed.
Following is a C language example of a DELETE policy function for a hierarchical (non-set)
CONSTRAINT that implements the MAC policy.
// udf_DeleteClassification.c
#define SQL_TEXT Latin_Text
#include <sys/types.h>
#include "sqltypes_td.h"
#DEFINE UNCLASSIFIED 1
void DeleteClassification(short int *RowClassification,
char *DeleteAllowed)
{
// Row can only be deleted if labelled unclassified
if (*RowClassification == UNCLASSIFIED)
// DELETE is allowed
*DeleteAllowed = 'T';
else
// DELETE is not allowed
*DeleteAllowed = 'F';
return;
}

Following is the DDL that would be used to create the above example DELETE policy
function. Note specifically the use of the required INPUT_ROW parameter name construct.
REPLACE FUNCTION SYSLIB.DeleteClassification
(INPUT_ROW smallint)
RETURNS char(1)
SPECIFIC SYSLIB.DeleteClassification
LANGUAGE C
DETERMINSTIC
NO SQL
EXTERNAL NAME 'cs!DeleteClassification!udf_DeleteClassification.c'
PARAMETER STYLE TD_GENERAL;

Following is a C language example of a DELETE policy function for a non-hierarchical (set)


CONSTRAINT that implements the MAC policy.
// udf_DeleteCompartment.c
#define SQL_TEXT Latin_Text
#include <sys/types.h>
#include "sqltypes_td.h"
typedef unsigned char byte;
void DeleteCompartment(byte *RowCompartments,

18

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

char *DeleteAllowed,
int *RowCompartments_i,
int *DeleteAllowed_i)
{
// Policy is that row can be deleted only if its compartments are NULL
// If row compartments are NULL, then DELETE is allowed
if (*RowCompartments_i == -1)
*DeleteAllowed = 'T';
else
// DELETE is not allowed
*DeleteAllowed = 'F';
*DeleteAllowed_i = 0;
return;
}

Following is the DDL that would be used to create the above example DELETE policy
function. Note specifically the use of the required INPUT_ROW parameter name construct.
REPLACE FUNCTION SYSLIB.DeleteCompartment
(INPUT_ROW byte(8))
RETURNS char(1)
SPECIFIC SYSLIB.DeleteCompartment
LANGUAGE C
DETERMINSTIC
NO SQL
EXTERNAL NAME 'cs!DeleteCompartment!udf_DeleteCompartment.c'
PARAMETER STYLE SQL;

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

19

Teradata Row Level Security

5. CONSTRAINT Objects
Teradata Row Level Security introduces a new type of database object called a
CONSTRAINT which defines a relationship between a RLS-protected table and a user.
CONSTRAINT objects define the set of valid values to be associated with table rows and
which are used for row-level filtering. Values are specified in the CONSTRAINT definition
as name:value pairs.
CONSTRAINT objects are further used to specify the set of policy functions that will be
executed to enforce the security policy. All policy functions must exist in the SYSLIB
database in order to be specified as part of a CONSTRAINT.
A user must be granted the CONSTRAINT DEFINITION access right in order to CREATE,
ALTER, or DROP CONSTRAINT objects.
There are two types of CONSTRAINT objects: hierarchical (non-set) and non-hierarchical
(set). Hierarchical (non-set) CONSTRAINTs define a single hierarchical level of security.
This type of CONSTRAINT would be used to define the Classification level of a MAC
security label. For example, hierarchical levels might be represented as Top Secret, Secret,
Confidential, and Unclassified. Non-hierarchical (set) CONSTRAINTs allow for row-level
filtering by most any type of grouping organization, department, region, country, job
function, etc. This type of CONSTRAINT would be used to define the optional
Compartment element of a MAC security label. For example, compartments might be
represented by countries such as USA, Canada, UK, France, and Germany.
5.1 Hierarchical (Non-set) CONSTRAINT
Hierarchical (non-set) CONSTRAINTs are defined by a data type of SMALLINT. Valid
values for this type of CONSTRAINT are 1 10,000 inclusive (a value of 0 is not valid). The
definition also specifies whether or not NULL values are allowed.
The CREATE CONSTRAINT statement is used to create a hierarchical (non-set)
CONSTRAINT object. The syntax for this statement is defined as follows:

Name:value pairs and policy functions can be added, dropped, or replaced for an existing
hierarchical (non-set) CONSTRAINT using the ALTER CONSTRAINT statement.
However, no alterations are allowed if the CONSTRAINT names or object is currently
assigned to a user, profile, or table. If the VALUES clause is included then the set of

20

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

name:value pairs specified replace the existing set of name:value pairs for the
CONSTRAINT. Policy functions can only be added to the CONSTRAINT object definition
if functions for the corresponding function types are not already defined for the
CONSTRAINT. The syntax for this statement is defined as follows:

A hierarchical (non-set) CONSTRAINT object may be dropped if it is no longer required.


However, the CONSTRAINT can only be dropped if it is not assigned to a user, profile, or
table and is not referenced by a hash/join index or view. The syntax for this statement is
defined as follows:

The SHOW CONSTRAINT statement can be used to display the SQL text used to create a
hierarchical (non-set) CONSTRAINT object. A user must be granted either the
CONSTRAINT DEFINITION or CONSTRAINT ASSIGNMENT access right in order to
SHOW a CONSRAINT. The syntax for this statement is defined as follows:

Following is an example of a hierarchical (non-set) CONSTRAINT object that is created to


define and implement a MAC security label classification level. This example defines four
hierarchical security levels and specifies policy functions to enforce a security policy for
SELECT, INSERT, UPDATE, and DELETE requests.
CREATE CONSTRAINT Classification SMALLINT, NOT NULL,
VALUES (TopSecret:4, Secret:3, Confidential:2, Unclassified:1)
SELECT SYSLIB.SelectClassification,
INSERT SYSLIB.InsertClassification,
UPDATE SYSLIB.UpdateClassification,
DELETE SYSLIB.DeleteClassification;

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

21

Teradata Row Level Security

5.2 Non-hierarchical (Set) CONSTRAINT


Non-hierarchical set) CONSTRAINTs are defined by a data type of BYTE(n) where n may
indicate a type up to a maximum of 32 bytes. Name:value pairs specified for this type of
CONSTRAINT may have values of 1 256 inclusive depending upon the value of n (a value
of 0 is not valid). The definition also specifies whether or not NULL values are allowed.
The BYTE(n) data type serves as a bitmap to represent the values specified. The value 1
corresponds to the highest order bit of the CONSTRAINT type, a value of 2 corresponds to
the next highest order bit, and so forth. This is important to understand because the column
within a table for which the CONSTRAINT is assigned must be populated with the correct bit
representation. As an example, the following depicts a CONSTRAINT of type BYTE(8) and
demonstrates the corresponding bit representation for values of 1, 14, 39, and 52 resulting in
a hex value of 8004000020001000xb.

The CREATE CONSTRAINT statement is used to create a non-hierarchical (set)


CONSTRAINT object. The syntax for this statement is defined as follows:

Name:value pairs and policy functions can be added, dropped, or replaced for an existing nonhierarchical (set) CONSTRAINT using the ALTER CONSTRAINT statement. However, no
alterations are allowed if any CONSTRAINT names are currently assigned to a user or profile
or if the CONSTRAINT object is currently assigned to a table. If the VALUES clause is
included then the set of name:value pairs specified replace the existing set of name:value
pairs for the CONSTRAINT. The syntax for this statement is defined as follows:

22

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

A non-hierarchical (set) CONSTRAINT object may be dropped if it is no longer required.


However, the CONSTRAINT can only be dropped if it is not assigned to a user, profile, or
table. The syntax for this statement is defined as follows:

The SHOW CONSTRAINT statement can be used to display the SQL text used to create a
non-hierarchical (set) CONSTRAINT object. A user must be granted either the
CONSTRAINT DEFINITION or CONSTRAINT ASSIGNMENT access right in order to
SHOW a CONSRAINT. The syntax for this statement is defined as follows:

Following is an example of a non-hierarchical (set) CONSTRAINT object that is created to


define and implement a MAC security label compartments element. This example defines
five compartments and specifies policy functions to enforce a security policy for SELECT,
INSERT, UPDATE, and DELETE requests.
CREATE CONSTRAINT Compartment BYTE(8), NULL,
VALUES (USA:1, Canada:2, UK:3, France:4, Germany:5)
SELECT SYSLIB.SelectCompartment,
INSERT SYSLIB.InsertCompartment,
UPDATE SYSLIB.UpdateCompartment,
DELETE SYSLIB.DeleteCompartment;

For this example, the values specified for the CONSTRAINT have the following hex values
and corresponding bit representations:
USA:1
8000000000000000xb
1000000000000000000000000000000000000000000000000000000000000000

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

23

Teradata Row Level Security

Canada:2 4000000000000000xb
0100000000000000000000000000000000000000000000000000000000000000
UK:3
2000000000000000xb
0010000000000000000000000000000000000000000000000000000000000000
France:4 1000000000000000xb
0001000000000000000000000000000000000000000000000000000000000000
Germany:5 0800000000000000xb
0000100000000000000000000000000000000000000000000000000000000000

Further, in this example, a compartment that represents Canada and France would have values
as follows:
5000000000000000xb
0101000000000000000000000000000000000000000000000000000000000000

24

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

6. CONSTRAINT Assignment
CONSTRAINT objects may be assigned as required to users, profiles, and tables.
6.1 Assigning CONSTRAINT Names to Users
Any defined CONSTRAINT name can be assigned as an attribute of a database user to enable
access to RLS-protected tables. The assignment must include one or more names from the set
of name:value pairs from the CONSTRAINT object definition which are to be valid for the
user. If the assignment is for a hierarchical (non-set) CONSTRAINT and includes multiple
names then one of the names should be indicated as DEFAULT. (If no DEFAULT is
indicated then the first name specified will become the DEFAULT.) The CONSTRAINT
name indicated as DEFAULT will be made active for the session upon user logon. The
assignment of a non-hierarchical (set) CONSTRAINT to users does not include the
specification of DEFAULT names since the entire set of CONSTRAINT names is made
active for the session upon user logon.
If one or more names from a CONSTRAINT object being assigned to a user are already
assigned to the user, then the specified name(s) replace the name(s) from the previous
assignment.
A user may be assigned names from a maximum of six (6) hierarchical (non-set)
CONSTRAINT objects and a maximum of two (2) non-hierarchical (set) CONSTRAINT
objects.
A user must be granted the CONSTRAINT ASSIGNMENT access right in order to assign
CONSTRAINT names to a user.
The CREATE USER and MODIFY USER statements are used to assign CONSTRAINT
names to a user. The basic syntax for assigning CONSTRAINT names to a user is defined as
follows:

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

25

Teradata Row Level Security

The MODIFY USER statement is used to remove CONSTRAINT name assignments from a
user. This is done by setting the set of valid CONSTRAINT names to NULL. The basic
syntax for removing CONSTRAINT name assignments from a user is defined as follows:

Following is an example of the creation of a user with the assignment of names from two
CONSTRAINT objects:
CREATE USER user000001 AS
PERM = 1e6, PASSWORD = xxx,
CONSTRAINT = Classification (Secret DEFAULT, Confidential),
CONSTRAINT = Compartment (USA, France);

Once CONSTRAINT names have been assigned to a user, the specified CONSTRAINT
names will be made active for the users session upon the next logon and will be evaluated by
the CONSTRAINT policy functions to filter access to rows upon access to tables protected by
the associated CONSTRAINT objects.
Following is an example of changing a CONSTRAINT name assignment for a user:
MODIFY USER user000001 AS
CONSTRAINT = Classification (TopSecret, Secret DEFAULT);

Following is an example of removing a CONSTRAINT name assignment from a user:


MODIFY USER user000001 AS
CONSTRAINT = Classification (NULL);

6.2 Assigning CONSTRAINT Names to Profiles


Any defined CONSTRAINT name can be assigned as an attribute of a database profile. The
profile can subsequently be assigned to one or more database users to enable access to RLSprotected tables. The assignment must include one or more names from the set of name:value
pairs from the CONSTRAINT object definition which are to be valid for the user. If the
assignment is for a hierarchical (non-set) CONSTRAINT and includes multiple names then
one of the names should be indicated as DEFAULT. (If no DEFAULT is indicated then the
first name specified will become the DEFAULT.) The CONSTRAINT name indicated as
DEFAULT will be made active for the session upon logon by a user that has been assigned
the profile. The assignment of non-hierarchical (set) CONSTRAINT names to profiles does
not include the specification of DEFAULT names since the entire set of CONSTRAINT
names is made active for the session upon logon by a user that has been assigned the profile.

26

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

If one or more names from a CONSTRAINT object being assigned to a profile are already
assigned to the profile, then the specified name(s) replace the name(s) from the previous
assignment.
A profile may be assigned names from a maximum of six (6) hierarchical (non-set)
CONSTRAINT objects and a maximum of two (2) non-hierarchical (set) CONSTRAINT
objects.
A user must be granted the CONSTRAINT ASSIGNMENT access right in order to assign
CONSTRAINT names to a profile.
The CREATE PROFILE and MODIFY PROFILE statements are used to assign
CONSTRAINT names to a profile. The basic syntax for assigning CONSTRAINT names to
a profile is defined as follows:

The MODIFY PROFILE statement is used to remove CONSTRAINT name assignments from
a profile. This is done by setting the set of valid CONSTRAINT names to NULL. The basic
syntax for removing CONSTRAINT name assignments from a profile is defined as follows:

Following is an example of the creation of a profile with the assignment of names from two
CONSTRAINT objects and the subsequent assignment of that profile to a user:
CREATE PROFILE p_group_1 AS
CONSTRAINT = Classification (Secret, Confidential DEFAULT),
CONSTRAINT = Compartment (USA, France, Germany);
MODIFY USER user000002 AS PROFILE = p_group_1;

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

27

Teradata Row Level Security

If a user assigned to a profile containing a CONSTRAINT name assignment has already been
directly assigned one or more names from the CONSTRAINT object, then the
CONSTRAINT names assignment via the profile takes precedence.
Once CONSTRAINT names have been assigned to a user via a profile, the specified
CONSTRAINT names will be made active for the users session upon the next logon and will
be evaluated by the policy functions to filter access to rows upon access to tables protected by
the associated CONSTRAINT objects.
Following is an example of changing a CONSTRAINT name assignment for a profile:
MODIFY PROFILE p_group_1 AS
CONSTRAINT = Classification (Secret DEFAULT, Confidential);

Following is an example of removing a CONSTRAINT name assignment from a profile:


MODIFY PROFILE p_group_1 AS
CONSTRAINT = Classification (NULL);

6.3 Assigning CONSTRAINT Objects to Tables


6.3.1 Base Tables

Any defined CONSTRAINT object can be assigned to a database table to enforce row-level
policies for filtering of rows on access to the table. Assignment of a CONSTRAINT object to
a table results in a column being added to the table with the same name and data type of the
CONSTRAINT object. This column can only be populated with values specified in the
definition of the CONSTRAINT object, or NULL if the CONSTRAINT object has been
defined to allow NULLs.
A table may be assigned a maximum of five (5) CONSTRAINT objects and may include any
combination of hierarchical (set) and non-hierarchical (non-set) CONSTRAINTs. The
PRIMARY INDEX for the table cannot include any CONSTRAINT object columns although
any secondary INDEX defined for the table may include CONSTRAINT object columns if
desired. CONSTRAINT object columns cannot be included in a PARTITION BY expression.
A table that is assigned CONSTRAINT objects should not include referential integrity (RI) or
CHECK or UNIQUE constraints. If the table is defined with these constraints then no rowlevel security policies will be enforced for the constraint checks.
Assignment of CONSTRAINT objects to global temporary or volatile tables is not supported
since access to these tables is limited to a single session.
A user must be granted the CONSTRAINT ASSIGNMENT access right in order to assign
CONSTRAINT objects to a table.

28

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

The CREATE TABLE and ALTER TABLE statements are used to assign CONSTRAINT
objects to a table. The basic syntax for assigning CONSTRAINT objects to a table is defined
as follows:

The ALTER TABLE statement may also be used to remove CONSTRAINT object
assignments from a table. Row-level policies for a CONSTRAINT will no longer be enforced
once the CONSTRAINT object assignment has been removed. The basic syntax for
removing CONSTRAINT object assignments is defined as follows:

Similar to other table columns, a CONSTRAINT object assignment cannot be removed if the
associated CONSTRAINT object column is included as part of an index.
Following is an example of the creation of a table with two CONSTRAINT object
assignments:
CREATE TABLE Systems
(Column_1 INTEGER, Column_2 INTEGER, Column_3 INTEGER,
Classification CONSTRAINT, Compartment CONSTRAINT);

Once CONSTRAINT objects have been assigned to a table, the policy functions defined by
the CONSTRAINT objects will be executed to enforce the CONSTRAINT policy upon any
subsequent access to the table unless the requesting user has been granted the appropriate
OVERRIDE CONSTRAINT rights.

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

29

Teradata Row Level Security

The CONSTRAINT object columns must be populated with values specified by the
name:value pairs defined for the corresponding CONSTRAINT objects. For hierarchical
(non-set) CONSTRAINT objects, valid values for the column are the values from the
name:value pairs. For non-hierarchical (set) CONSTRAINT objects, valid values from the
name:value pairs are populated as bit positions in the BYTE(n) column where a value of 1
corresponds to the highest-order bit, a value of 2 corresponds to the next highest-order bit, etc.
For example, using the CONSTRAINT object definition from previous examples, the
following demonstrates valid values populated in the CONSTRAINT object columns to
indicate specific Classification levels and Compartment categories.

6.3.2 Error Tables

By default, an error table created on a RLS-protected table will include the same set of
CONSTRAINT object columns as the RLS-protected table and the associated row-level
security policies will be similarly enforced on access to the error table. However, generation
of the CONSTRAINT object columns can be suppressed.
Suppression of the generation of CONSTRAINT object columns for error tables is done using
the NO RLS clause on the CREATE ERROR TABLE statement. The syntax for this
statement is defined as follows:

If a target table that is assigned one or more CONSTRAINT objects is being loaded using
FastLoad, MultiLoad, or the TPT Load or Update operators, then the corresponding
application error table will be defined with the same CONSTRAINT object columns. Note,
however, INSERT policy function UDFs are not executed when a row is inserted into the
error table. The value for the CONSTRAINT object columns is taken from the row generated
for the target table.

30

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

When an ALTER TABLE statement adds a referencing column to a table, rows that violate
referential integrity are inserted into an error table that is created internally by the Parser
during processing of the ALTER TABLE ADD RI statement. If the table is assigned one or
more CONSTRAINT objects then this error table will be defined with the same
CONSTRAINT object columns.
6.3.3 Save Tables

ALTER TABLE statements that modify a primary index (ALTER TABLE MODIFY
PRIMARY INDEX) or revalidate a partitioned primary index (ALTER TABLE
REVALIDATE PRIMARY INDEX) may specify a WITH INSERT INTO save_table clause.
In this case, if during the modification or revalidation any row for which the partition number
evaluates to a value outside the valid range of 1 - 65,535, inclusive, will be inserted into the
user-defined save table. If the table being altered is assigned or more CONSTRAINT objects,
then the save table must also be assigned the same CONSTRAINT objects.

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

31

Teradata Row Level Security

7. Session CONSTRAINTs
Following a logon by a user that has been assigned one or more CONSTRAINT names (either
directly or via a profile), the corresponding values from the CONSTRAINT assignment are
assigned to the session and maintained as part of the session state. These values are then
input as the CURRENT_SESSION argument to be evaluated by the CONSTRAINT policy
functions upon access to a RLS-protected table.
For hierarchical (non-set) CONSTRAINT objects, the value corresponding to the name
indicated as DEFAULT, or the first name from the CONSTRAINT assignment if no
DEFAULT is indicated, is initially assigned to the session. For non-hierarchical (set)
CONSTRAINT objects, the value corresponding to the set of names specified in the
CONSTRAINT assignment is initially assigned to the session. (If a user has no
CONSTRAINT object assignments, then NULL is assigned to the session and the user can
only access rows in a corresponding RLS-protected table if granted the appropriate
OVERRIDE CONSTRAINT rights.)
A user may change the CONSTRAINT values assigned to a session by setting any valid
name, or set of names, allowed by the name:value pairs indicated in the assignment of the
CONSTRAINT object to the user.
A session may be assigned a maximum of six (6) hierarchical (non-set) CONSTRAINT
values and a maximum of two (2) non-hierarchical (set) CONSTRAINT values.
The SET SESSION statement is used to add or remove CONSTRAINT value assignments to
or from a session. The basic syntax is defined as follows:

The value(s) corresponding to the name(s) specified in the SET SESSION CONSTRAINT
statement replace the corresponding assignments for the session CONSTRAINT. Specifying
NULL for a CONSTRAINT object indicates that the CONSTRAINT assignment is to be
removed from the session state.
Following is an example of setting the CONSTRAINT assignments for a session:
SET SESSION
CONSTRAINT = Classification (Confidential),
CONSTRAINT = Compartment (France, Germany);

The HELP SESSION statement may be used to display the current CONSTRAINT
assignments for a session. The basic syntax is defined as follows:

32

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

Following is an example of the results from executing a HELP SESSION CONSTRAINT


statement following the above SET SESSION CONSTRAINT example:
.sidetitles on
.foldline on
HELP SESSION CONSTRAINT;
*** Help information returned. One row.
*** Total elapsed time was 1 second.
Constraint1Name
Constraint1Value
Constraint2Name
Constraint2Value

CLASSIFICATION
3
COMPARTMENT
'1800000000000000'xb

For middle-tier applications using the Trusted Sessions feature, if the PROXYUSER asserted
through a SET QUERY_BAND statement is a permanent database user, then the session
CONSTRAINT values are set to the default values for that permanent database user. The
proxy user may use the SET SESSION CONSTRAINT statement to set the session
CONSTRAINT values for any valid name, or set of names, allowed by the name:value pairs
indicated in the assignment of the CONSTRAINT object to the permanent database user. If
the PROXYUSER asserted through a SET QUERY_BAND statement is an application user
(i.e., there is no corresponding permanent database user) then no session CONSTRAINT
values are set since it is not possible to assign CONSTRAINT names to this type of proxy
user. As such, the proxy user is not allowed to access RLS-protected tables.

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

33

Teradata Row Level Security

8. CONSTRAINT Auditing
Teradata Row Level Security includes extensions to the Access Logging function to allow for
auditing of the enforcement of row-level security policies.
The BEGIN LOGGING statement is used to define Access Logging rules for auditing the
enforcement of row-level security policies. The basic syntax is defined as follows:

Valid operations are:


SELECT
INSERT
UPDATE
DELETE
OVERRIDE SELECT
OVERRIDE INSERT
OVERRIDE UPDATE
OVERRIDE DELETE
OVERRIDE DUMP
OVERRIDE RESTORE
For SQL operations (SELECT, INSERT, UPDATE, or DELETE), an audit record is
generated to indicate that a corresponding CONSTRAINT policy function is executed for the
query. For OVERRIDE CONSTRAINT operations, an audit record is generated upon the
check for the corresponding access right.
The DENIALS keyword is not applicable for SQL operations (SELECT, INSERT, UPDATE,
or DELETE). If the DENIALS keyword is specified for any of the OVERRIDE
CONSTRAINT operations, then an audit record will be generated when a user attempts to
access the associated RLS-protected table and does not have an assigned session
CONSTRAINT value for the specified CONSTRAINT object or does not have the
appropriate OVERRIDE CONSTRAINT right.

34

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

If ON DATABASE or ON USER is indicated then the Access Logging rule will be applied on
access to any tables within the specified database_name or user_name that are assigned the
specified CONSTRAINT object or names from the CONSTRAINT object. If ON TABLE is
indicated then the specified table_name must be a table assigned the specified CONSTRAINT
object and the Access Logging rule will be applied on access to the table.
The END LOGGING statement is used to delete Access Logging rules for auditing the
enforcement of row-level security policies. The basic syntax is defined as follows:

Following is an example of the definition of an Access Logging rule to audit all SELECT
policy enforcement operations for a specified user for any tables assigned a specific
CONSTRAINT object:
BEGIN LOGGING ON EACH SELECT FOR CONSTRAINT Classification BY user000001;

Following is an example of the definition of an Access Logging rule to audit INSERT and
UPDATE operations bypassing the CONSTRAINT policy by any user for any tables assigned
a specific CONSTRAINT object:
BEGIN LOGGING ON EACH OVERRIDE INSERT, OVERRIDE UPDATE
FOR CONSTRAINT Compartment;

Following is an example of the definition of an Access Logging rule to audit denied RLS
operations by any user for a specific table assigned a specific CONSTRAINT object:
BEGIN LOGGING DENIALS ON EACH ALL FOR CONSTRAINT Compartment
ON TABLE Systems;

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

35

Teradata Row Level Security

9. Limits and Restrictions


The following sections discuss limits and restrictions applicable to the initial release of
Teradata Row Level Security.
9.1 CONSTRAINT Object Limits
For a hierarchical (non-set) CONSTRAINT object, the value defined in a name:value pair is
limited to a maximum of 10,000.
For a non-hierarchical (set) CONSTRAINT object, the BYTE(n) definition is limited to a
minimum of 1 byte (BYTE(1)) and a maximum of 32 bytes (BYTE(32)). This allows for up
to 256 bit positions. The value defined in a name:value pair is limited to a maximum of 8 * n
where n is from the BYTE(n) defined for the CONSTRAINT object.
9.2 User and Profile Limits
A user or profile may be assigned names from a maximum of six (6) hierarchical (non-set)
CONSTRAINT objects.
A user or profile may be assigned names from a maximum of two (2) non-hierarchical (set)
CONSTRAINT objects.
9.3 Session Limits
A maximum of six (6) hierarchical (non-set) CONSTRAINT values may be set for a session.
A maximum of two (2) non-hierarchical (set) CONSTRAINT values may be set for a session.
9.4 Primary Indexes
The primary index defined for a RLS-protected table cannot include any CONSTRAINT
object columns. Similarly, the primary index defined for a join or hash index cannot include
any CONSTRAINT object columns.
9.5 Primary and Foreign Keys
CONSTRAINT objects should not be assigned to tables defined with Primary Keys or
Foreign Keys. If a CONSTRAINT object is assigned to such tables, then the associated rowlevel security policies are not enforced upon user access to the tables.
9.6 CHECK and UNIQUE Constraints
Neither CHECK nor UNIQUE constraints can be defined on CONSTRAINT object columns.
If a CONSTRAINT object is assigned to a table defined with CHECK or UNIQUE
constraints, then no row-level security policies will be enforced for the constraint checks.

36

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

9.7 Partitioning Expressions


When defining a partitioned RLS-protected table, the PARTITION BY expressions cannot
include any CONSTRAINT object columns.
9.8 Compression
CONSTRAINT object columns cannot be compressed using either multi-value compression
(MVC) or algorithmic compression (ALC). Block-level compression (BLC) is allowed for
RLS-protected tables.
9.9 Views
If a view definition references multiple RLS-protected tables, then all of the referenced RLSprotected tables must be assigned the same set of CONSTRAINT objects.
View definitions may include both RLS-protected tables and non-RLS-protected tables.
9.10 Join and Hash Indexes
Join and hash indexes may reference only a single RLS-protected table. All CONSTRAINT
object columns defined for the table must be included in the join or hash index definition.
9.11 Macros and Stored Procedures
RLS-protected tables may be accessed by macros and stored procedures. Note, however,
while access rights on such tables are typically enforced based upon the owner of the macro
or stored procedure, row-level filtering is based upon the session CONSTRAINT values for
the user that executes the macro or stored procedure.
Macros and stored procedures may not include DCL or DDL statements for row-level security
administration.
9.12 Triggers
Triggers cannot be defined to include references to RLS-protected tables.
9.13 Replication Groups
Replication Groups cannot be defined to include RLS-protected tables.
9.14 Statistics
A user must be granted the OVERRIDE SELECT CONSTRAINT right in order to execute a
COLLECT STATISTICS or HELP STATISTICS statement on a RLS-protected table.

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

37

Teradata Row Level Security

9.15 Table Joins


SQL joins of RLS-protected tables are allowed only if the RLS-protected tables are assigned
the same set of CONSTRAINT objects.
SQL joins may include both RLS-protected tables and non-RLS-protected tables.
9.16 Compound Statements
If a RLS-protected table is referenced in a compound statement (e.g., MERGE INTO-USING,
INSERT-SELECT), then all tables referenced in the statement must be RLS-protected and
assigned the same set of CONSTRAINT objects.
Note that during processing of compound statement, the CONSTRAINT policy functions are
only executed on access to the source table and are not executed for the target table. If the
user executing the compound statement does not have appropriate OVERRIDE
CONSTRAINT rights on the target table, then values for the CONSTRAINT columns are
taken from the corresponding CONSTRAINT columns of the source table. If the user
executing the compound statement has appropriate OVERRIDE CONSTRAINT rights on the
target table, then values for the CONSTRAINT columns may be taken from the
corresponding CONSTRAINT columns of the source table or may be supplied by the
statement.
9.17 ARCHIVE, COPY and RESTORE
ARCHIVE source tables and COPY/RESTORE destination tables must be assigned the same
set of CONSTRAINT objects.
NOTE: The row-level security policy cannot be reliably enforced following COPY or
RESTORE of a table if the name:value pairs of one or more assigned CONSTRAINT objects
have been altered or removed subsequent to the ARCHIVE of the table. If the COPY or
RESTORE operation detects that a CONSTRAINT object has been altered subsequent to the
ARCHIVE of the table then a warning is issued: Restored/Copied data table security may be
compromised because a security constraint is inconsistent between the backup and disk. The
COPY or RESTORE operation is allowed to complete, but security may be compromised.
9.18 Aggregate and Ordered Analytical Functions
Aggregate functions (e.g. SUM, COUNT, MAX, MIN, AVG) and ordered analytical
functions (e.g. MAVG, CSUM, RANK, etc.) are allowed on RLS-protected tables. While not
a limitation, per se, it should be recognized that when used these functions will only be
applied to columns from rows for which access is allowed by the row-level security policy.

38

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

10. Data Dictionary


The following provides a high level description of data dictionary system tables and system
views that have been added or modified to support Teradata Row Level Security. For more
detailed information, refer to the Data Dictionary reference manual.
10.1 System Tables
Four new system tables have been added for support of Teradata Row Level Security.
Additionally, columns have been added in five existing system tables for support of Teradata
Row Level Security.
10.1.1 SecConstraints

The SecConstraints system table is stores information about CONSTRAINT objects.


SecConstraints
Column Name

Data Type

Description

ConstraintName (UPI)

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
BYTE(4) NOT NULL

Name of the CONSTRAINT object

ConstraintId (USI)
DataType

CHAR(2) LATIN UPPERCASE


NOT CASESPECIFIC NOT NULL

ColumnWidth
AssigneeCount

SMALLINT NOT NULL


SMALLINT NOT NULL

Nullable

CHAR(1) LATIN UPPERCASE


NOT CASESPECIFIC NOT NULL

RequestText

VARCHAR(12500) UNICODE
NOT CASESPECIFIC
BYTE(4) NOT NULL

CreateUID
CommentString
CreateTimeStamp

VARCHAR(255) UNICODE
NOT CASESPECIFIC
TIMESTAMP(0) NOT NULL

LastAlterTimeStamp

TIMESTAMP(0) NOT NULL

LastAlterUID

BYTE(4) NOT NULL

Unique identification number for the CONSTRAINT


object
Indicates the data type of the CONSTRAINT object
column
The possible values are:

I1 = BYTE(n) data type

I2 = SMALLINT data type


Indicates the width of the CONSTRAINT object column
The number of instances of the assignment of the
CONSTRAINT object
Indicates whether a NULL value is allowed for the
CONSTRAINT object column.
The possible values are:

Y = Yes NULL is allowed

N = No NULL is not allowed


The text of the most recent data definition statement that
was used to create or alter the CONSTRAINT object
Unique identification number for the user that created the
CONSTRAINT object
User-supplied text or commentary on the CONSTRAINT
object
The date and time that the CONSTRAINT object was
created
The date and time that the CONSTRAINT object was last
altered
Unique identification number for the user that last altered
the CONSTRAINT object

10.1.2 ConstraintFunctions

The ConstraintFunctions system table stores information about the policy functions (UDFs)
defined for CONSTRAINT objects.
ConstraintFunctions
Column Name

Data Type

Description

ConstraintId (NUPI

BYTE(4) NOT NULL

Unique identification number for the CONSTRAINT

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

39

Teradata Row Level Security

ConstraintFunctions
Column Name

Data Type

Composite USI)
StatementAction
(Composite USI)

CHAR(2) LATIN UPPERCASE


NOT CASESPECIFIC NOT NULL

FunctionDBId

BYTE(4) NOT NULL

FunctionId (NUSI)

BYTE(4) NOT NULL

FunctionName

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL

Description
object
Indicates the request type for which the policy function is
executed
The possible values are:

SE = SELECT

IN = INSERT

UP = UPDATE

DE = DELETE
Unique identification number for the database containing
the policy function (UDF)
Unique identification number for the policy function
(UDF)
Name of the policy function (UDF)

10.1.3 ConstraintValues

The ConstraintValues system table stores information about the name:value pairs defined for
CONSTRAINT objects.
ConstraintValues
Column Name

Data Type

Description

ConstraintID (NUPI
Composite USI)
ConstraintVal
(Composite USI)
ValueName

BYTE(4) NOT NULL

Unique identification number for the CONSTRAINT


object
Value from the name:value pair defined for the
CONSTRAINT object
Name from the name:value pair defined for the
CONSTRAINT object
Indicates how the value is used
The possible values are:

Y = value is used as a bit position

N = value is used as a SMALLINT

ValueIsBitPos

SMALLINT NOT NULL


VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
CHAR(1) LATIN UPPERCASE
NOT CASESPECIFIC NOT NULL

10.1.4 AsgdSecConstraints

The AsgdSecConstraints system table stores information about CONSTRAINT objects and
associated name:value pairs that have been assigned to users and profiles.
AsgdSecConstraints
Column Name

Data Type

Description

AssigneeId (NUPI)

BYTE(4) NOT NULL

ConstraintId (NUSI)

BYTE(4) NOT NULL

ConstraintVal

SMALLINT NOT NULL

IsDefault

CHAR(1) LATIN UPPERCASE


NOT CASESPECIFIC NOT NULL

ByteSize

SMALLINT NOT NULL

Unique identification number for the user or profile that is


assigned names from the CONSTRAINT object
Unique identification number for the CONSTRAINT
object for which names are assigned to the user or profile
Value from the CONSTRAINT name:value pair assigned
to the user or profile
Indicates whether the CONSTRAINT value assigned to the
user or profile is the DEFAULT value for the assignment.
The possible values are:

Y = value is the DEFAULT

N = value is not the DEFAULT


Indicates the size of the BYTE(n) data type for a nonhierarchical (set) CONSTRAINT object

40

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

AsgdSecConstraints
Column Name

Data Type

Description

AssignorId

BYTE(4) NOT NULL

AssigneeKind

CHAR(1) LATIN UPPERCASE


NOT CASESPECIFIC NOT NULL

AssignTimeStamp

TIMESTAMP(0) NOT NULL

Unique identification number for the user assigning the


CONSTRAINT object to the user or profile
Indicates whether the assignee is a user or profile.
The possible values are:

U = Assignee is a user

P = Assignee is a profile
The date and time that the CONSTRAINT object was
assigned to the user or profile

10.1.5 TVM

The TVM system table stores information about database objects. One column has been
added to this table for support of Teradata Row Level Security.
TVM
Column Name

Data Type

Description

MACFlag

CHAR(1) LATIN UPPERCASE


NOT CASESPECIFIC

Indicates whether a table is protected by row-level


security
The possible values are:

Y the table is assigned a CONSTRAINT object

N (or NULL) the table is not assigned a


CONSTRAINT object

10.1.6 TVFields

The TVFields system table stores information about columns of a table. One column has
been added to this table for support of Teradata Row Level Security.
TVFields
Column Name

Data Type

Description

ConstraintID

BYTE(4) NOT NULL

Unique identification number for the CONSTRAINT


object that is associated with the column of a table; NULL
if no CONSTRAINT object is associated with the column

10.1.7 SessionTbl

The SessionTbl system table stores information about sessions. Sixteen (16) columns have
been added to this table for support of Teradata Row Level Security.
SessionTbl
Column Name

Data Type

Description

Constraint1Id

BYTE(4) NOT NULL

Constraint1Val

SMALLINT

Constraint2Id

BYTE(4) NOT NULL

Unique identification number for the first hierarchical


(non-set) CONSTRAINT object for which values are
assigned to the session; NULL if CONSTRAINT values
are assigned to the session
Value for the first hierarchical (non-set) CONSTRAINT
that is assigned to the session; NULL if CONSTRAINT is
not assigned to the session
Unique identification number for the second hierarchical
(non-set) CONSTRAINT object t for which values are
assigned to the session; NULL if CONSTRAINT values

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

41

Teradata Row Level Security

SessionTbl
Column Name

Data Type

Constraint2Val

SMALLINT

Constraint3Id

BYTE(4) NOT NULL

Constraint3Val

SMALLINT

Constraint4Id

BYTE(4) NOT NULL

Constraint4Val

SMALLINT

Constraint5Id

BYTE(4) NOT NULL

Constraint5Val

SMALLINT

Constraint6Id

BYTE(4) NOT NULL

Constraint6Val

VARBYTE(32)

Constraint7Id

BYTE(4) NOT NULL

Constraint7Val

VARBYTE(32)

Constraint8Id

BYTE(4) NOT NULL

Constraint8Val

SMALLINT

Description
are assigned to the session
Value for the second hierarchical (non-set) CONSTRAINT
that is assigned to the session; NULL if CONSTRAINT is
not assigned to the session
Unique identification number for the third hierarchical
(non-set) CONSTRAINT object for which values are
assigned to the session; NULL if CONSTRAINT values
are assigned to the session
Value for the third hierarchical (non-set) CONSTRAINT
that is assigned to the session; NULL if CONSTRAINT is
not assigned to the session
Unique identification number for the fourth hierarchical
(non-set) CONSTRAINT object for which values are
assigned to the session; NULL if CONSTRAINT values
are assigned to the session
Value for the fourth hierarchical (non-set) CONSTRAINT
that is assigned to the session; NULL if CONSTRAINT is
not assigned to the session
Unique identification number for the fifth hierarchical
(non-set) CONSTRAINT object for which values are
assigned to the session; NULL if CONSTRAINT values
are assigned to the session
Value for the fifth hierarchical (non-set) CONSTRAINT
that is assigned to the session; NULL if CONSTRAINT is
not assigned to the session
Unique identification number for the sixth hierarchical
(non-set) CONSTRAINT for which values are assigned to
the session; NULL if CONSTRAINT values are assigned
to the session
Value for the sixth hierarchical (non-set) CONSTRAINT
that is assigned to the session; NULL if CONSTRAINT is
not assigned to the session
Unique identification number for the first non-hierarchical
(set) CONSTRAINT object for which values are assigned
to the session; NULL if CONSTRAINT values are
assigned to the session
Value for the first non-hierarchical (set) CONSTRAINT
that is assigned to the session; NULL if CONSTRAINT is
not assigned to the session
Unique identification number for the second nonhierarchical (set) CONSTRAINT object for which values
are assigned to the session; NULL if CONSTRAINT
values are assigned to the session
Value for the second non-hierarchical (set)
CONSTRAINT object that is assigned to the session;
NULL if CONSTRAINT object is not assigned to the
session

10.1.8 AccLogRuleTbl

The AccLogRuleTbl system table stores information about Access Logging rules. Nine (9)
columns have been added to this table for support of Teradata Row Level Security.
AccLogRuleTbl
Column Name

Data Type

Description

ConstraintId

BYTE(4)

Unique identification number for the CONSTRAINT

42

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

AccLogRuleTbl
Column Name

Data Type

Description

CHAR(3) LATIN NOT


CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL

object that is indicated for the rule; NULL if no


CONSTRAINT object is indicated for the rule
Indicates the logging rules in effect for the CONSTRAINT
DEFINITION privilege check
Indicates the logging rules in effect for the CONSTRAINT
ASSIGNMENT privilege check
Indicates the logging rules in effect for the OVERRIDE
INSERT CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
SELECT CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
UPDATE CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
DELETE CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
DUMP CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
RESTORE CONSTRAINT privilege check

(Composite UPI)
AcrConstrDef
AcrConstrAsgn
AcrOverrideIns
AcrOverrideSel
AcrOverrideUpd
AcrOverrideDel
AcrOverrideDump
AcrOverrideRestore

Note that the composite unique primary index defined for the AccLogRuleTbl table includes
the ConstraintID column. The UPI is defined as follows:
UNIQUE PRIMARY INDEX ( UserID ,DatabaseID ,TVMId ,ColumnId ,ConstraintId )

10.1.9 AccLogTbl

The AccLogTbl system table stores Access Log audit records. One column has been added to
this table for support of Teradata Row Level Security.
AccLogTbl
Column Name

Data Type

Description

ConstraintId

BYTE(4)

Unique identification number for the CONSTRAINT


object that is referenced for the access log record; NULL
if no CONSTRAINT object is referenced for the record

10.2 System Views


Five new system views have been added for support of Teradata Row Level Security.
Additionally, columns have been added in three existing system views for support of Teradata
Row Level Security.
10.2.1 SecConstraintsV[X]

The SecConstraintsv[X] system view contains information about CONSTRAINT objects.


SecConstraintsV[X]
Column Name

Data Type

Description

ConstraintName

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
CHAR(2) LATIN UPPERCASE
NOT CASESPECIFIC NOT NULL

Name of the CONSTRAINT object

DataType

Indicates the data type of the CONSTRAINT object


column
The possible values are:

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

43

Teradata Row Level Security

SecConstraintsV[X]
Column Name

Data Type

Nullable

CHAR(1) LATIN UPPERCASE


NOT CASESPECIFIC NOT NULL

AssigneeCount

SMALLINT NOT NULL

Creator

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
TIMESTAMP(0) NOT NULL

CreateTimeStamp

Description

I1 = BYTE(n) data type

I2 = SMALLINT data type


Indicates whether a NULL value is allowed for the
CONSTRAINT object column.
The possible values are:

Y = Yes NULL is allowed

N = No NULL is not allowed


The number instances of the assignment of the
CONSTRAINT object
Name of the user that created the CONSTRAINT object
The date and time that the CONSTRAINT object was
created

10.2.2 ConstraintFunctionsV

The ConstraintFunctionsV system view contains information about the policy functions
(UDFs) defined for CONSTRAINT objects.
ConstraintFunctionsV
Column Name

Data Type

Description

ConstraintName

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
CHAR(2) LATIN UPPERCASE
NOT CASESPECIFIC NOT NULL

Name of the CONSTRAINT object

Action

DatabaseName
FunctionName

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL

Indicates the request type for which the policy function is


executed
The possible values are:

SE = SELECT

IN = INSERT

UP = UPDATE

DE = DELETE
Name of the database containing the policy function
(UDF)
Name of the policy function (UDF)

10.2.3 ConstraintValuesV

The ConstraintValuesV system view contains information about the name:value pairs defined
for CONSTRAINT objects.
ConstraintValuesV
Column Name

Data Type

Description

ConstraintName

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
SMALLINT NOT NULL

Name of the CONSTRAINT object

ValueName
ValueConstant
ValueIsBitPos

44

CHAR(1) LATIN UPPERCASE


NOT CASESPECIFIC NOT NULL

Name from the name:value pair defined for the


CONSTRAINT object
Value from the name:value pair defined for the
CONSTRAINT object
Indicates how the value is used
The possible values are:

Y = value is used as a bit position

N = value is used as a SMALLINT

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

10.2.4 UsrAsgdSecConstraintsV[X]

The UsrAsgdSecConstraintsV[X] system view contains information about CONSTRAINT


objects and associated name:value pairs that have been assigned to users.
UsrAsgdSecConstraintsV[X]
Column Name

Data Type

Description

UserName

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
CHAR(1) LATIN UPPERCASE
NOT CASESPECIFIC NOT NULL

Name of the user assigned names from the CONSTRAINT


object
Name of the CONSTRAINT object

ConstraintName
ValueName
IsDefault

Assignor

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL

Name from the name:value pair defined for the


CONSTRAINT object
Indicates whether the value corresponding to the
CONSTRAINT name assigned to the user is the
DEFAULT value for the assignment.
The possible values are:

Y = value is the DEFAULT

N = value is not the DEFAULT


Name of the user assigning the CONSTRAINT object to
the user

10.2.5 ProfileAsgdSecConstraintsV[X]

The ProfileAsgdSecConstraintsV[X] system view contains information about CONSTRAINT


objects and associated name:value pairs that have been assigned to profiles.
ProfileAsgdSecConstraintsV[X]
Column Name

Data Type

Description

ProfileName

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
CHAR(1) LATIN UPPERCASE
NOT CASESPECIFIC NOT NULL

Name of the profile assigned names from the


CONSTRAINT object
Name of the CONSTRAINT object

ConstraintName
ValueName
IsDefault

Assignor

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL

Name from the name:value pair defined for the


CONSTRAINT object
Indicates whether the value corresponding to the
CONSTRAINT name assigned to the profile is the
DEFAULT value for the assignment.
The possible values are:

Y = value is the DEFAULT

N = value is not the DEFAULT


Name of the user assigning the CONSTRAINT names to
the profile

10.2.6 ColumnsV[X]

The ColumnsV[X] system view contains information about columns of a table. One column
has been added to this view for support of Teradata Row Level Security.
TVFields
Column Name

Data Type

Description

ConstraintId

BYTE(4) NOT NULL

Unique identification number for the CONSTRAINT


object that is associated with the column of a table; NULL
if no CONSTRAINT object is associated with the column

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

45

Teradata Row Level Security

10.2.7 AccLogRulesV

The AccLogRulesV system view contains information about Access Logging rules. Nine (9)
columns have been added to this view for support of Teradata Row Level Security.
AccLogRulesV
Column Name

Data Type

Description

ConstraintName

VARCHAR(128) UNICODE
NOT CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL
CHAR(3) LATIN NOT
CASESPECIFIC NOT NULL

Name of the CONSTRAINT object

AcrConstrDef
AcrConstrAsgn
AcrOverrideIns
AcrOverrideSel
AcrOverrideUpd
AcrOverrideDel
AcrOverrideDump
AcrOverrideRestore

Indicates the logging rules in effect for the CONSTRAINT


DEFINITION privilege check
Indicates the logging rules in effect for the CONSTRAINT
ASSIGNMENT privilege check
Indicates the logging rules in effect for the OVERRIDE
INSERT CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
SELECT CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
UPDATE CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
DELETE CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
DUMP CONSTRAINT privilege check
Indicates the logging rules in effect for the OVERRIDE
RESTORE CONSTRAINT privilege check

10.2.8 AccessLogV

The AccessLogV system view contains Access Log audit records. One column has been
added to this table for support of Teradata Row Level Security.
AccessLogV
Column Name

Data Type

Description

ConstraintId

BYTE(4)

Unique identification number for the CONSTRAINT


object that is referenced for the access log record; NULL
if no CONSTRAINT object is referenced for the record

46

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

11. Error Messages


The following summarizes error messages that may be encountered when using Teradata Row
Level Security. For more detailed information, refer to the Messages reference manual.
9020 Restore/Copy Dictionary stopped because a security constraint is
inconsistent between the backup and disk.
The restore/copy dictionary request for the restore or copy of an RLS protected table or a database containing an
RLS-protected table was stopped because the last alter timestamp of a security constraint is different between the
dictionary backup and the associated entry on disk.
9021 Restore/Copy table stopped because user does not have the required
privilege for the operation.
The restore/copy table request for the restore or copy of an RLS-protected table was stopped because the user
does not have the required Override Dump Constraint or Override Restore Constraint privilege.
9400 The statement involves a Row Level Security functionality that is not
supported.
The submitted SQL statement involves a Row Level Security functionality that is not supported yet. This error
code is returned in the following instances in the first release (14.0) of RLS:
a) Triggers involving a protected table,
b) Replication.
c) Abort statement referencing a constraint column.
9401 Illegal operation on a table secured at row level.
A data table under Row Level Security in a post 13.0 release was reverted (backed down) to a 13.0 release. As
RLS was introduced in 13.1, a reverted table will be exposed to unauthorized access if DMLs are allowed on it.
The only operation allowed on such a table is DROP TABLE.
9402 The constraint object name constraint_name specified in the Create
Constraint statement is a duplicate of an existing name.
The submitted SQL statement contains a constraint name which already exists in the server.
9403 The specified security constraint constraint_name does not exist.
The constraint name specified in the statement does not exist in the dictionary tables.
9404 Duplicate value name value_name within a security constraint.
A security constraint can be defined with multiple value names and their corresponding codes. However, the
name of each value must be unique within the constraint definition.
9405 Duplicate value code for value name value_code within a security
constraint.
A security constraint can be defined with multiple value names and their corresponding codes. However, the
name and code of each value must be unique within the constraint definition.
9406 Invalid value code for value name value_name within a security
constraint.
A security constraint can be defined as either a smallint or a byte array data type. The value code specific in the
constraint statement is invalid for the defined data type. The acceptable value code for a smallint constraint type
is between 1 and 10000 inclusive. The acceptable value code for a byte array data type is an integer bit number
which is between 1 and 8 inclusive times the number of bytes in the constraint.
9407 UDF specified in constraint option does not exist.
A security constraint option in the statement specifies a UDF for execution of the security policy. The specified
function does not exist.

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

47

Teradata Row Level Security

9408 UDF "%VSTR" specified with an invalid function type.


A security constraint option in the statement specifies a UDF for execution of the security policy which is not a
scalar function. Aggregate and table functions are not supported for implementation of a constraint security
policy.
9409 Invalid constraint name constraint_name defined in the statement.
A statement has been submitted which contains a constraint name that does not exist. All security constraints
must be defined before they can be assigned to users, profiles or tables.
9410 Too many constraint columns are defined for the table.
A create or alter table statement has been submitted which defines more constraints than are currently allowed
for a table. The maximum allowed is 5.
9411 Duplicate constraint name has been defined for a table.
A create or alter statement has been submitted which contains a duplicate constraint name for the table. A
constraint can only be defined once in a table.
9412 Referenced constraint column does not exist in table.
A Security Constraint column name which does not exist has been referenced in the statement.
9413 An invalid constraint name has been assigned to the user.
A create/modify user statement has been submitted which contains an invalid security constraint name.
9414 A value name which does not exist has been defined for a security
constraint.
A statement assigned a constraint been submitted. The statement contains a non-existent value name for a
security constraint.
9415 More than one default value has been defined for a security
constraint.
A statement assigned a constraint has been submitted. The statement attempts to define more than one value
name as the default for the constraint.
9416 The same security name has been assigned more than once to a user.
Explanation: A create/modify user statement has been submitted which contains multiple instances of the same
security constraint name.
9417 User has not been assigned the security credential value_name.
A set session statement has been submitted which contains a value name that is not assigned to the user.
9418 The total number of object_name constraints assigned is over the
limit.
This error is returned when a CREATE USER, MODIFY USER, CREATE PROFILE, MODIFY PROFILE, or
SET SESSION CONSTRAINT statement exceeded the maximum allowable constraint assignments.
Assignments are limited to a total of 6 non-set and 2 set constraints per user or profile. VSTR can be "non-set",
"set" or a null string.
9419 Set session statement has defined more than one value name for a nonset constraint.
A set session statement has been submitted which contains more than one value name for the same non-set
security constraint.
9420 A UDF defined for a security constraint does not exist or it is
invalid.
A security constraint has been assigned to a table which was an object of the DML statement. The constraint
defined a UDF which covered the action of the DML statement. Either the UDF could not be found because it

48

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

had been deleted or moved or the UDF had been changed so that it no longer met the requirements for a UDF
written to enforce the security policy of a constraint.
9421 Duplicate constraint name has been specified in DDL statement.
A statement has been submitted which contains a duplicate constraint name.
9422 Request size exceeds the maximum of 12500 characters
The user specified a request that exceeds the specified limit.
9423 Column column_name is not a constraint column.
The user tried to grant an Override privilege on a column that is not a constraint column.
9424 Security column column_name cannot be renamed in an object.
An alias is defined in the view or derived table definition for a security column in the base table.
9425 Row Level Security privilege cannot be granted to PUBLIC.
The user tried to grant one of the following privileges to PUBLIC:
CONSTRAINT DEFINITION
CONSTRAINT ASSIGNMENT
OVERRIDE INSERT CONSTRAINT
OVERRIDE SELECT CONSTRAINT
OVERRIDE UPDATE CONSTRAINT
OVERRIDE DELETE CONSTRAINT
9427 An Override Constraint privilege can only be granted on a protected
table or constraint column.
The following privileges can only be granted on a protected table:
OVERRIDE INSERT CONSTRAINT
OVERRIDE SELECT CONSTRAINT
OVERRIDE UPDATE CONSTRAINT
OVERRIDE DELETE CONSTRAINT
9428 Security constraint constraint_name is not set in the current session.
Explanation: The user must specify a session value name for the non-nullable constraint column.
9429 Duplicate function name function_name within a security constraint.
A security constraint can be defined with a user defined function (UDF) for each of the statement actions.
However, the name of each constraint UDF must be unique within the constraint definition.
9430 The database specified for the UDF function_name is invalid.
A security constraint statement specifies a UDF for execution of the security policy which is not contained in the
SYSLIB database.
9431 Duplicate statement action within a security constraint.
A security constraint can be defined with a statement action user defined function (UDF). However, only one
constraint UDF may be specified for each statement action.
9433 Input values specified for constraint columns may be replaced by
session constraint values.
The query is a parameterized insert into a protected table and the user has not been granted OVERRIDE
INSERT CONSTRAINT privilege on one or more constraint columns. Any input value specified for a constraint
column for which the user does not have OVERRIDE INSERT CONSTRAINT privilege will be replaced by the
users session value for the constraint.
9434 Row Level Security Override privileges cannot be granted with GRANT
OPTION.

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

49

Teradata Row Level Security

Privileges pertaining to overriding RLS cannot be granted WITH GRANT OPTION. These privileges are:
OVERRIDE INSERT CONSTRAINT
OVERRIDE SELECT CONSTRAINT
OVERRIDE UPDATE CONSTRAINT
OVERRIDE DELETE CONSTRAINT
OVERRIDE DUMP CONSTRAINT
OVERRIDE RESTORE CONSTRAINT.
9435 Invalid input for constraint column column_name.
A simple insert operation must specify a constant value only for a constraint column.
9441 Illegal definition involving a protected table.
This error code is returned in the following situations:
a) A join index definition does not include all security constraints in a protected table, or references another
table besides the protected table.
b) A view definition references protected tables that do not have identical security constraints.
9442 There is no constraint value set for the current session.
The HELP SESSION CONSTRAINT statement did not find any constraint for the current session.
9443 An invalid value was specified for the constraint column column_name.
As the user has been granted the OVERRIDE INSERT CONSTRAINT or OVERRIDE UPDATE
CONSTRAINT privilege, the input value specified for the constraint column must either be a numeric value or
NULL.
9444 A multi-table operation is executed and the tables do not have the
same security constraints.
In the first release of the security constraint functions it is required that all tables involved in a multi-table DML
statement have the same security constraint definitions. The statement may be a merge, insert/select, join, or one
involving a join.
9447 Override Insert Constraint privilege is required for specifying a
value for constraint column column_name.
The user has does not have Override Insert Constraint privilege on a constraint column and has either:
1) specified a value for the column, or
2) submitted a compound statement (INSERT-SELECT or MERGE-INTO) and the insert values for the
column were not taken directly from the source table. Without Override Insert Constraint privilege, a
MERGE INTO with an INSERT component can only reference the source base table in the USING
clause, and not a view or derived table based on the source table.
9448 User has not been assigned the security constraint constraint_name.
A set session statement contains a security constraint that has not been previously assigned to the user.
9449 The constraint being altered or dropped is in use.
An ALTER CONSTRAINT or DROP CONSTRAINT statement references a constraint that is still in use. A
constraint is considered in use if it is assigned to a user or role, or is used as a constraint column in a protected
table.
9450 Security constraint column column_name cannot be renamed.
'ALTER TABLE <tablename> RENAME <cname1> { AS | TO } <cname2>.' is illegal when the column being
renamed is a constraint column.
9451 Invalid assignment for constraint column column_name.
This error is returned if the input specified for a target table's constraint column is not coming from a matching
constraint column in the source table.

50

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

9457 Override Update Constraint privilege is required for update of


constraint column column_name.
Constraint columns can only be updated if the user has the OU privilege.
9458 Parameter style of UDF function_name is incompatible with security
column's nullability attribute.
A constraint column's nullability attribute must match up with its INSERT or UPDATE constraint function's
parameter style as follows:
Nullable - parameter style must be SQL.
Non-nullable - parameter style must be TD_GENERAL.
9459 The constraint being altered does not have a
<insert|select|update|delete> function.
An ALTER CONSTRAINT statement is trying to drop a constraint function that is not defined for the constraint.
9460 Source is a query referencing a protected table.
If the source references a protected table, only
'CREATE TABLE <table2> AS <table1> ... ;' is legal.
'CREATE TABLE <table2> AS (<subquery on table1>) ... ;' is illegal.
9461 Default value cannot be defined on a set constraint.
A statement assigning a constraint has been submitted. The statement attempts to define a default value on a set
constraint. The DEFAULT keyword is applicable to non-set constraints only.
9467 The usage of security constraint constraint_name in the <PK|FK def,
etc> is not allowed.
The CREATE, or ALTER, statement contains an invalid usage of a security constraint. Security constraint
columns cannot be a component of:
- a primary index definition
- a primary key definition
- a foreign key definition
- a partitioning expression
- a UNIQUE constraint
9468 The usage of security constraint constraint_name in the CHECK
constraint is not allowed.
The CREATE, or ALTER, statement contains an invalid usage of a security constraint in a CHECK constraint
definition. Security constraint columns cannot be a component of an expression in a CHECK constraint.
9469 A temporary or queue table definition cannot have any security
constraint column.
Security constraints are not allowed in the definition of a global temporary, volatile, or queue table. Queue
tables currently have a limitation that disallows a WHERE clause when a row is being CONSUMEd. This
precludes the addition of security constraint predicates when queue table rows are consumed.
9487 The constraint constraint_name does not have a function defined for
<INSERT|SELECT|UPDATE|DELETE> operations.
The query involves access of protected data and a constraint function controlling the query is not recognized by
the system. Probable causes are:
a) no constraint function is defined for the statement action (INSERT, SELECT, UDPATE, or DELETE),
b) there is some incompatibility between the SQL definition of the constraint UDF and the C language
definition of the UDF routine.
A constraint UDF must be defined for the constraint before the operation is permitted.
9488 CREATE text for the specified constraint is too long for SHOW
CONSTRAINT.

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

51

Teradata Row Level Security

The text that would be used in a single CREATE CONSTRAINT statement for the specified constraint is too
long to return via SHOW CONSTRAINT.
9489 The specified audit frequency for a protected table is illegal.
'LAST' and 'FIRST AND LAST' cannot be specified in a BEGIN LOGGING statement if the object under audit
is a protected table.
9490 The FOR CONSTRAINT clause may only be specified for auditing a
protected table.
The object of access logging must be a protected table if the FOR CONSTRAINT clause is specified.
9491 Statements that administer Row Level Security are not allowed in
macros or stored procedures.
DDL and DCL statements for RLS administration will not be allowed to be defined in macros or stored
procedures.
9492 The UDF function_name is already defined for the security constraint
being altered.
When trying to add a UDF for the security constraint the UDF name should be valid i.e. it must be unique within
the constraint definition.
9493 The statement action <INSERT|SELECT|UPDATE|DELETE> is already defined
for the security constraint being altered.
When trying to add a UDF with a statement action for the security constraint, that action should not be already
defined for the constraint. If it is defined then a 'REPLACE' action should be used instead.
9494 The column level privilege cannot be granted on the security
constraint constraint_name.
It is not allowed to grant any column level DML privilege i.e. INSERT, UPDATE and SELECT on a column
defined as a RLS constraint.
9495 Constraint column column_name cannot be defined with any column
attribute.
A security constraint column cannot have any of the column attributes such as compress, default, unique etc.
9496 Cannot add a constraint column to a protected table with a join or
hash index.
Constraint columns cannot be added to a protected table with a join index or a hash index because the join or
hash index definition has to include all constraint columns in the table.
9497 The datatypes of the constraint constraint_name and an input parameter
of the constraint function function_name do not match.
The data type of the constraint function's input parameter must be the same as the data type of the constraint.
9531 Override Select Constraint privileges are required for this operation.
Override Select Constraint privileges on both the target and save tables are required for altering the partitioned
primary index of a protected table.
9532 Target and save tables do not have identical security constraints.
The table being altered is a protected table and the save table is not created with the same constraints defined in
the target table.
9533 The revoke statement is illegal.
The user is trying to revoke either
a) an Override Constraint privilege on a table that is not protected, or
b) a RLS privilege from PUBLIC. RLS privileges cannot be granted to PUBLIC.

52

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

9534 The NO RLS option is applicable to creating an error table for a


protected table only.
When the NO RLS clause is specified, an unprotected error table will be created for a protected data table. It is
illegal to specify the clause if the data table is not protected.
9542 A security constraint with the name constraint_name already exists.
Examine the Teradata SQL statement and verify that the request is correct. Change the statement to specify a
different name and resubmit the request.
9548 Source rows did not include all constraint columns in the source
table.
A MERGE-INTO or INSERT-SELECT statement involved a view or derived table that did not include all
constraint columns in the source table.

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

53

Teradata Row Level Security

12. Future Enhancements


Enhancements are planned for future releases of Teradata Row Level Security. The following
Requests for Change (RFCs) have been written for this feature.
RFC 155936
Row Level Security support for AJI, ins-sel, foreignkey references
Implementation of this RFC will relax current restrictions that limit join indexes to a single
RLS-protected table, require all tables referenced in a compound statement to be protected,
and do not allow foreign key references on CONSTRAINT object columns.

RFC 155943
RLS: Apply constraint function if session constraint value exists
Implementation of this RFC will enforce row-level security policies on any query for which
an applicable CONSTRAINT value is set for the session regardless of whether or not the user
submitting the query has been granted the associated OVERRIDE CONSTRAINT right.

RFC 155944
RLS: Allow bulk loads from unprotected tables into protected tables
Implementation of this RFC will allow bulk load operations (INSERT-SELECT, MERGEINTO, etc.) from non-RLS-protected tables into RLS-protected tables.

54

Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved 541-0009217 A03

Teradata Row Level Security

13. References
Teradata Database Security Administration
Release 14.0
B035-1100-111A
Teradata Database SQL Data Control Language
Release 14.0
B035-1149-111A
Teradata Database SQL Data Definition Language
Syntax and Examples
Release 14.0
B035-1144-111A
Teradata Database SQL Data Definition Language
Detailed Topics
Release 14.0
B035-1184-111A
Teradata Database SQL External Routine Programming
Release 14.0
B035-1147-111A
Teradata Database Data Dictionary
Release 14.0
B035-1092-111A
Messages
Teradata Database 14.0
Teradata Tools and Utilities 14.00
B035-1096-111A

541-0009217 A03 Teradata Confidential Copyright 2012 Teradata Corp. All Rights Reserved

55