The LIBACLINHERIT
parameter file option controls the ACL precedence of permission checks.
Precedence of permission checks includes inheriting the permissions
of the LIBNAME ACL for resources owned by the domain owner. In this
case, 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 where 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 accessor, the accessor gets these permissions.
-
If group-specific permissions are defined on the object
for the accessor's group, the accessor gets these permissions.
-
If LIBNAME ACL permissions are defined for the accessor,
the accessor gets the LIBNAME ACL permissions on the object.
-
If LIBNAME ACL permissions are defined for the accessor's
group, the accessor gets the LIBNAME ACL permissions on the object.
-
Else, the accessor gets UNIVERSAL ACLs on the resource.
An OWNER=
<owner-name>LIBACLINHERIT=YES domain statement
uses a slightly different methodology because of the OWNER= parameter.
When specifying the OWNER= parameter with LIBACLINHERIT=YES, the owner
can grant:
-
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
ALTER
access can be used with OWNER= and LIBACLINHERIT=YES to allow a user
or group to create a new resource in the domain. In some cases,
ALTER access is preferable to WRITE access for an OWNER= domain,
because ALTER access prevents users or groups that inherit WRITE
access from writing to, updating, or deleting resources that were
created by the domain owner. LIBNAME ALTER access with OWNER= and
LIBACLINHERIT=YES allows the owner to grant privileges to users to
create objects in the domain, and WRITE access can be used to inherit
write access to the owner's resources.
The following
is an example of SAS code submitted to SPD Server using LIBACLINHERIT.
The example begins by showing 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 ;