Permissions for Metadata-Bound Data :: SAS(R) 9.4 Guide to Metadata-Bound Libraries, Second Edition

Permissions on Secured Library and Table Objects

For secured library objects and secured table objects, SAS enforces the following special metadata-layer permissions:

Permissions for Metadata-Bound Data
Permission	Abbreviation	Actions Affected
Delete	D	Delete rows in a physical table. For example, in order to use SAS to delete data from a metadata-bound table, you need the Delete permission on the corresponding secured table object. You also need the Select permission on that object.
Insert	I	Add rows to a physical table. For example, in order to use SAS to add data to a metadata-bound table, you need the Insert permission on the corresponding secured table object.
Update	U	Update rows in a physical table. For example, in order to use SAS to update data in a metadata-bound table, you need the Update permission on the corresponding secured table object. You also need the Select permission on that object.
Select	S	Read rows within a physical table. For example, in order to use SAS to read data from a metadata-bound table, you need the Select permission on the corresponding secured table object.
Create Table	CT	Create a new physical table. For example, in order to use SAS to add a table to a metadata-bound library, you need the Create Table permission on the corresponding secured library object. Rename a physical table (if that action creates a new table, rather than overwriting a preexisting table). For example, if you rename TableA to TableB in a metadata-bound library that does not already contain a TableB, you need the Create Table permission on the corresponding secured library object. You also need the Alter Table permission on TableA’s corresponding secured table object.
Drop Table	DT	Delete a physical table. For example, in order to use SAS to delete a metadata-bound table, you need the Drop Table permission on the corresponding secured table object.1
Alter Table	AT	Replace a physical table. For example, in order to use SAS to replace a metadata-bound table, you need the Alter Table permission on the corresponding secured table object. Rename a physical table. For example, in order to use SAS to rename a metadata-bound table, you need the Alter Table permission on the corresponding secured table object. You also need the Create Table permission on the corresponding secured library object. Perform other administrative updates on a physical table, such as modifying variable names and labels. For example, in order to use SAS to change labels in a metadata-bound table, you need the Alter Table permission on the corresponding secured table object.
1A user who has Write access in the host layer can delete physical tables using operating system commands, regardless of whether the user has a grant of DT in the metadata layer. Any table replacements are detected through audit log entries. See Auditing for Metadata-Bound Libraries.

Permission Requirements

Introduction

This topic addresses tasks that are performed using SAS. Tasks that are instead performed using host commands are not subject to metadata-layer permission requirements. See Security Impact of Moving Tables.

Table-Level Tasks

The following table documents the effective metadata-layer grants on a secured table object that are required in order to perform certain tasks with that object.

Tip

Each of the following tasks is initiated by SAS against physical data (SAS data set files or SAS views). For data that is bound to metadata, SAS always enforces metadata-layer permission requirements before allowing access.

Metadata-Layer Permission Requirements for Selected Tasks
Task	Effective Grants (on the secured table object)
View data in a metadata-bound table	Select
Add rows to a metadata-bound table	Insert
Update rows in a metadata-bound table	Select, Update
Delete rows from a metadata-bound table	Select, Delete
Replace a metadata-bound table with a new version of data	Alter Table
Rename a metadata-bound table (for example, using PROC DATASETS with CHANGE)	Alter Table, Create Table1
Modify variable names or labels in a metadata-bound table (for example, using PROC DATASETS with MODIFY)	Alter Table
Copy a metadata-bound table out of a metadata-bound library (for example, using PROC COPY)	Select
Move a metadata-bound table out of a metadata-bound library (for example, using PROC COPY with MOVE)	Select, Drop Table
Delete a metadata-bound table from the file system (for example, using PROC DATASETS with DELETE)	Drop Table
1The Create Table permission is required on any target secured table object that will be overwritten. If there is no such object, then the Create Table permission is required on the parent library.

Library-Level Tasks

The following table documents which effective metadata-layer grants on which objects are required in order to perform certain library-level tasks.

Tip

Each of the following tasks is initiated by SAS against physical data. With metadata-bound libraries, SAS always enforces metadata-layer permission requirements before allowing access.

Metadata-Layer Permission Requirements for Selected Tasks
Task	Secured Data Folder	Secured Library Object	Secured Table Object
Bind a library to metadata1	WriteMemberMetadata	-	-
Unbind a metadata-bound library	WriteMemberMetadata	WriteMetadata	-
Add tables to a metadata-bound library (for example, using the COPY procedure)	-	Create Table	Alter Table2
1If the metadata identity that is used to bind a physical library to metadata doesn’t have effective metadata-layer grants of the data permissions, explicit grants are added to the new secured library object when it is created.
2Alter Table is required on any target table object that is overwritten. If there is no such table object, then Create Table is required on the parent library object.

Additional Considerations

The following additional requirements apply:

The metadata identity under which authorization decisions are requested must have the ReadMetadata permission for all applicable objects.
The host identity under which physical data is accessed must meet the usual host-layer requirements, such as the following:
- In order to view physical data, the host identity must have host-layer Read access to the data.
- In order to add, update, or delete a physical table, the host identity must have host-layer Write access to the target directory or file (in accordance with the host system’s requirements).
- In order to create, modify, or delete a metadata-bound library, the host identity must have host-layer control of the physical directory. For host-specific details, see Requirement for Host-Layer Control.
When accessing data from a client such as SAS Web Report Studio, users must also have appropriate permissions for the traditional library and table objects that are used to locate the data.

Requirement for Host-Layer Control

For actions other than validation, the requesting identity must have host-layer control of the target physical directory. This ensures that only users who have host control can bind, unbind, or modify passwords for a physical library.

The requesting SAS session (or workspace server) must run under a privileged host account as follows:

On UNIX, the account must be the owner of the directory.
On Windows, the account must have Full Control of the directory.
On z/OS, for UNIX file system libraries, the account must be the owner of the directory.
On z/OS, for direct-access bound libraries, the account must have RACF ALTER access authority to the library data set.

Identity in Authorization Evaluations

In general, metadata-layer access is evaluated against the metadata identity of the requesting user (the client), and host-layer access is evaluated against the server process identity (or, for a Base SAS session, the identity under which the session was initiated).

The following list documents some exceptions:

If access is through a SAS/CONNECT server that did not receive the requesting user’s metadata identity from the client session, metadata-layer authorization checks are made against the SAS/CONNECT server’s metadata identity. This unusual circumstance occurs if the server runs with the NOCONNECTMETACONNECTION option and is not a trusted peer of the metadata server.
If access is through a SAS/SHARE server that cannot impersonate the requesting user on a connection to the metadata server, and the target data is a remote view, then metadata-layer authorization checks are made against the SAS/SHARE server’s metadata identity. For example, metadata-layer authorization checks are made against the SAS/SHARE server’s metadata identity if that server runs with the AUTHENTICATE=OPTIONAL option and no client identity is established.

For access through a SAS/SHARE server that does impersonate the requesting user, an additional consideration is which client identity matters—the one that connects to the SAS/SHARE server, or the one that issues the LIBNAME statement. The following list provides details:

In both of the following cases, checks are under the metadata identity that corresponds to the user ID with which the client host authenticates to the SAS/SHARE server:
- Access is through view files and the REMOTEVIEW option is set to YES (the default value).
- Access is from a third-party client (such as ODBC, OLEDB, or JDBC).
Otherwise, checks are under the metadata identity in the client at the time that the LIBNAME statement is issued.