Controlling the Precedence of Permission Checks with the LIBACLINHERIT= Option

Precedence of permission checks includes inheriting the permissions of the LIBNAME ACL for resources owned by the domain owner. The LIBNAME ACL is used first to give READ or WRITE access to the domain, and then to inherit ACLs to resources that belong to the domain owner. When a user attempts to access resources in a domain in which the domain owner specifies LIBACLINHERIT=YES, the following ACL precedence of permissions checks are made on the resource:

If user-specific permissions are defined on the object for the user, the user gets these permissions.
If group-specific permissions are defined on the object for the user’s group, the user gets these permissions.
If LIBNAME ACL permissions are defined for the user, the user gets the LIBNAME ACL permissions on the object.
If LIBNAME ACL permissions are defined for the user’s group, the user gets the LIBNAME ACL permissions on the object.
Otherwise, the user gets UNIVERSAL ACLs on the resource.

An OWNER=<owner-name>LIBACLINHERIT=YES domain statement uses a slightly different methodology. When the owner specifies the OWNER= parameter with LIBACLINHERIT=YES, the owner can grant the following access levels:

READ access to allow a user or group to get a LIBNAME to the domain
ALTER access to allow a user or group to create new objects in the domain
CONTROL access to allow a user or group to modify the owner's LIBNAME ACL

The owner can use ALTER access with OWNER= and LIBACLINHERIT=YES to allow a user or group to create a new resource in the domain. ALTER access is sometimes preferable to WRITE access for an OWNER= domain. ALTER access prevents users or groups that inherit WRITE access from writing to, updating, or deleting resources that were created by the domain owner. When the owner uses LIBNAME ALTER access with OWNER= and LIBACLINHERIT=YES, the owner can grant privileges to users to create objects in the domain. The owner can use WRITE access to inherit WRITE access to the owner's resources.

The following example shows SAS code submitted to SPD Server using LIBACLINHERIT. The example begins with information in the libnames.parm file where domain names and paths are declared.

Contents of the libnames.parm file:

LIBNAME=libinher
PATHNAME=/IDX1/spdsmgr/spds45test/libinher
LIBACLINHERIT=YES
OWNER=admin ;

LIBNAME=noinher
PATHNAME=/IDX1/spdsmgr/spds45test/noinher
OWNER=admin ;

SAS code submitted to SPD Server by the user:

LIBNAME libinher sasspds 'libinher'
  server=gomez.5129
  user='admin'
  password='spds123' ;

LIBNAME noinher sasspds 'noinher'
  server=gomez.5129
  user='admin'
  password='spds123' ;

data libinher.admins_table
  noinher.admins_table ;

  do i = 1 to 10 ;
    output ;
end ;
run ;


/* LIBNAME access for user anonymous */
  PROC SPDO library=libinher ;


/* Admin owns these ACLs */
  set acluser admin ;


/* Add a LIBNAME ACL to d1 */
  add acl / LIBNAME ;


/* Modify LIBNAME ACL Domain d1  */
/* Allow users in Group 1        */
/* read-only access to domain    */

modify acl / LIBNAME read ;

list acl _all_ ;
quit ;


/* Set up LIBNAME access for  */
/* user anonymous             */
PROC SPDO library=noinher ;


/* Specify who owns these ACLs */
  set acluser admin ;


/* add a LIBNAME ACL to d1 */
  add acl / LIBNAME ;


/* Modify LIBNAME ACL Domain d1 */
/* Allow users in Group 1 read- */
/* only access to the domain    */

modify acl / LIBNAME read ;

list acl _all_ ;
quit ;

LIBNAME a_inher sasspds 'libinher'
  server=gomez.5129
  user='anonymous' ;

LIBNAME a_noher sasspds 'noinher'
  server=gomez.5129
  user='anonymous' ;

PROC PRINT data=a_inher.admins_table ;
  title 'with libaclinher' ;
run ;

PROC PRINT data=a_noher.admins_table ;
  title 'without libaclinher'
run ;