SAS administrators now have another tool to keep SAS users from straying off their permitted path: the LOCKDOWN system option. The option was introduced in "stealth mode" for SAS 9.4. In SAS 9.4M1, it became a true, documented option. For the official guide to creating "locked-down servers", see the SAS 9.4 Intelligence Platform: Security Administration Guide

LOCKDOWN's primary purpose is to allow admins to close two perceived holes when supporting SAS programmers:

1. It shuts down any SAS language feature that provides direct or indirect access to the operating system shell. This includes PROC GROOVY, and the DATA step Java Object and others. You also need to make sure that NOXCMD (shell command integration) and NORLANG (R language integration) are in place, since those avenues would circumvent any SAS-enforced system access.
2. It allows file access to only those directories that a SAS admin adds to a "whitelist". This is the key benefit, since it prevents users from assigning arbitrary file-based libraries.

Enabling LOCKDOWN is a two-step process. First, you add the -LOCKDOWN option to the SAS command-line or config file. In a standard deployment, you can add it to the Workspace startup script. I tested this by adding it to my ../Config/Lev1/SASApp/WorkspaceServer/WorkspaceServer_usermods.bat file:

Set USERMODS_OPTIONS=-LOCKDOWN 

if %USERNAME%==sascrh(
  Set USERMODS_OPTIONS=
) else (
  Set USERMODS_OPTIONS=-LOCKDOWN 
)

The second step is to use the LOCKDOWN statement somewhere in the SAS autoexec chain to list the operating system folders that you want the user to be able to access. Again, I need some logic to conditionally set this only when in LOCKDOWN mode. In my test, I modified WorkspaceServer/autoexec_usermods.sas to include:

 %macro lockit;
 %if %sysfunc(getoption(LOCKDOWN)) = LOCKDOWN %then %do;
   /* this adds the user's home directory */
   lockdown path="?FOLDERID_Profile";  
   lockdown list;
 %end;
 %else %PUT "System running under NOLOCKDOWN.";
 %mend;
 options source;
 %lockit;

Note: I could avoid this script-level logic by simply creating another SAS Workspace context in SAS Management Console. I would then group certain users to use the locked-down one instead of the unlocked version. I would using SAS Metadata groups to control visibility/access into the appropriate servers.

If I didn't add the ?FOLDERID_Profile (Windows only, UNIX uses '~') to the list of allowed paths, my SAS Enterprise Guide users would receive a funny message when connecting to the SAS Workspace. As an inset, I also included the view of the SASApp tree; notice that it has no Files navigation: