SPD Server ACL Security Model

Overview of the ACL Security Model

SPD Server provides an Access Control List (ACL) based security system. The ACL-based security is enabled by default. You are encouraged to run SPD Server using ACLs. ACLs add little overhead to SPD Server in terms of execution speed and disk space consumption. ACLs keep files private to individual users and within groups.
Only disable ACLs if your computing environment requires free access of any user to any other user's files. Migrating from a non-ACL environment to an ACL-based environment is not simple, so use ACLs if you foresee needing security controls at a future time. Files created by SPD Server running ACLs only should be accessed by SPD Servers running ACLs. Likewise, areas created without ACLs should be accessed only by SPD Servers using -NOACL.
SPD Server comes bundled with the SAS Management Console. The SAS Management Console is a GUI utility that an SPD Server administrator can use to manage passwords and ACLs. The SAS Management Console manages passwords using the same capabilities that the psmgr utility provides, and the SAS Management Console also manages ACLs using the same capabilities provided by PROC SPDO.

Enabling ACL Security

Overview of Enabling ACL Security

You enable SPD Server security with the -ACL option on the spdsserv command. Numerous security features are in effect with ACLs enabled.

UNIX File-Level Protection with ACL Security

Each session of SPD Server is attached to a user with some UNIX or Windows user ID. If SPD Server runs on UNIX, all files created by the software are protected according to the UNIX file creation permissions associated with that UNIX user's ID. The SPD Server only can read or write files that have the appropriate file and directory access permissions to the SPD Server's user's ID. Use the UNIX unmask command to restrict the creation permissions.

User/Password Validation

SAS users must issue a user ID and password with the LIBNAME statement in order to connect to SPD Server. The user ID and password are verified against an SPD Server user ID table set up by the system administrator. Password expiration can be enforced by the system administrator via the psmgr administration tool for the user ID table or through the SAS Management Console, if it is installed and configured for SPD Server. In either of the two environments, the system administrator can prevent logins under the anonymous user ID by placing user 'anonymou' in the user ID table with a password unknown to the SAS users.

Control of LIBNAME Domains by the System Administrator with ACL Security

The system administrator defines the valid LIBNAME domains with entries in the LIBNAME parameter file for each SPD Server. The PATHNAME= specification defines the file system for the LIBNAME. LIBNAME= specifications provide the access route to the file system. Restricting knowledge of the LIBNAME= specification information restricts access to the corresponding file systems.

User Ownership of LIBNAME Domains

In the LIBNAME parameter file, the system administrator can attach the OWNER= specification to any defined LIBNAME domain. Only the system user whose user ID matches the OWNER= specification can create tables in this domain. (However, that user can grant other users read or write access rights through ACLs that were issued from the SAS LIBNAME statement.)

User Ownership of Tables

Each table created is tagged with the SPD user ID (referred to as the owner) who created it. Only the owner or ACLSPECIAL users can access a table. (However, the owner can grant access to other users through ACLs by adding a LIBNAME ACL with PROC SPDO.)

Example Server Setup with ACL Security

The following command invokes SPD Server with ACL support enabled and configures it with the specified LIBNAME domain definitions.
   spdssrv -ACL -acldir
     InstallDir/site -nameserver samson
     -LIBNAMEfile libnames.parm
The libnames.parm file contains:
   LIBNAME=public pathname=/disk1/public;
   LIBNAME=qadata pathname=/disk2/qadata
     owner=qamgr;
   LIBNAME=marketing pathname=/disk3/marketing
     owner=mktmgr;
   LIBNAME=clinical pathname=/disk4/clinical
     owner=drzeuss;
SPD Server is invoked connecting to the name server running on machine 'samson'. The password file listing all valid system users resides in directory 'InstallDir/site'. LIBNAME domains 'public' 'qadata', 'marketing' and 'clinical' are registered with the name server. The /disk1/public, /disk2/qadata, /disk3/marketing, and /disk4/clinical directories must exist and the user ID that invokes spdssrv must have read and write access to them.
The following LIBNAME statements connect SAS clients to the data areas:
   LIBNAME open sasspds 'public'
     host='samson'
     user='employee'
     prompt=yes;

   LIBNAME pres sasspds 'clinical'
     host='samson'
     user='ceo'
     prompt=yes;

   LIBNAME report sasspds 'marketing'
     host='samson'
     user='ceo'
     aclgrp='mrktng'
     prompt=yes;

   LIBNAME efficacy sasspds 'clinical'
     host='samson'
     user='drfda'
     prompt=yes;
Additionally, ACLs can be created on the LIBNAME domains themselves and the resources that are created within them. The simplest way to do this is using PROC SPDO. The following example demonstrates this:
   LIBNAME clin sasspds 'clinical'
     host='samson'
     user='drzeuss'
     prompt=yes;
   PROC SPDO lib=clin;
   set acluser;
   add ACL /
     LIBNAME groupread;
   modify ACL /
     LIBNAME drfgood=(y,y,,y);
   quit;
The owner of the LIBNAME domain 'clinical' has granted permission to other members of his or her ACL group to the LIBNAME domain to have READ access to the domain. This permits these users to perform SAS LIBNAME assignments to the domain. Users not belonging to the owner's ACL group will not even be permitted to make LIBNAME assignments to the 'clinical' domain. The owner has also granted READ, WRITE, and CONTROL access to the explicit user 'drfgood'. This enables 'drfgood' to make LIBNAME assignments and write new files to the 'clinical' domain, and to also alter the LIBNAME ACL permissions if desired.

Disabling ACL Security

Overview of Disabling ACL Security

You disable SPD Server security by using the -NOACL option with the spdsserv command. When ACLs are disabled, there are almost no security restrictions in the SPD Server environment. Anyone can access SPD Server, as long as they know the LIBNAMES that are defined by the system administrator in the -LIBNAME file.

UNIX File-Level Protection with ACL Security Disabled

In UNIX, each SPD Server session runs under a UNIX user ID. All files created by SPD Server therefore are protected according to the UNIX file creation permissions of that UNIX user ID. Use the UNIX 'umask' command to restrict the desired creation permissions. File permissions are based on the permissions of the directory where the file was created.

Control of LIBNAME Domains by the System Administrator without ACL Security

The system administrator defines the valid LIBNAME domains with entries in the LIBNAME parameter file for each SPD Server. PATHNAME= defines the file system for the LIBNAME. LIBNAME= provides the access route to the file system. Restricting knowledge of the LIBNAME= labels restricts access to the corresponding file system.

Example Server Setup without ACL Security

The following command invokes SPD Server without ACL security enabled.
spdssrv -noacl -acldir
InstallDir/site -nameserver samson
-libnamefile libnames.parm
The libnames.parm file contains:
     LIBNAME=open_access
       pathname=/disk1/sas_tables;
     LIBNAME=mgmt_access
       pathname=/disk2/managers/data;
SPD Server is invoked, connecting to the name server running on the machine called 'samson'. Despite no ACLs, a password file is still required in the directory called InstallDir/site.
Note: InstallDir is a documentation substitute for the actual path specification for the directory where SPD Server is installed on a particular machine.
LIBNAME domains 'open_access' and 'mgmt_access' are registered with the name server. The /disk1/sas_tables and /disk2/managers/data directories must exist, and the user ID that invokes spdssrv must have read and write access to those directories. The following LIBNAME statements connect a SAS client to the data areas:
   LIBNAME open sasspds 'open_access'
     host='samson';
   LIBNAME mgmt sasspds 'mgmt_access'
     host='samson';