Month: June 2011

SAS® platform administrators can get quite familiar with the SAS NOXCMD option, usually when someone asks why their programs that used to work (in a different SAS version or execution environment) are now failing. Perhaps the programs ran ok with SAS Enterprise Guide 4.1 using a SAS 9.1.3 server but now fail with SAS Enterprise Guide 4.2 using a SAS 9.2 server. Maybe they were developing some code using SAS Display Manager (I know it’s no longer de rigueur but us old-timers will still confess to using it from time to time – some even quite proudly as a badge of honour!). When that code gets deployed in a stored process on a SAS 9.2 server it then starts failing (hmmm perhaps we should have been developing and testing it in SAS Enterprise Guide or SAS Data Integration Studio after all ;)). You may have seen logs with this error:

1          filename lscmd pipe 'ls -al /tmp';
ERROR: Insufficient authorization to access PIPE.
ERROR: Error in the FILENAME statement.

… or maybe this one:

ERROR: Shell escape is not valid in this SAS session.
1          %sysexec mkdir /tmp/test;

… these are the common error messages seen when trying to run external operating systems in a NOXCMD constrained environment.

If you do a Google search for these messages you might find these resources:

• Chris Hemedinger’s blog post “Using the X and SYSTASK commands from SAS Enterprise Guide” from Nov 2009, where he also explained how to overcome it with a single workstation installation of SAS Enterprise Guide and Foundation SAS.
• SAS Problem Note 41058: Unable to submit X commands from SAS® Enterprise Guide® connecting to a SAS® Metadata Server when running SAS® 9.2 or later. I noticed at the end of this SAS note it says “… the commands will execute on the metadata server and not on your local PC“. Whilst this would be the case if it were the SASMeta – Workspace Server (a workspace server restricted to metadata administrators that runs on the metadata server machine), it would only be the case for the SASApp – Workspace Server if the workspace server happened to be on the same machine as the metadata server. In many of the installations I see, the metadata server runs on its own dedicated machine, and so this is often not the case. To clarify, it runs the commands on the host machine that the SASApp – Workspace Server is configured to run on.

In the rest of this post I am going to provide some more info, from the platform administrator’s perspective, and try to offer some suggestions and pointers to additional resources that help you with the goal of trying to work with the NOXCMD option. Ideally we want to try to retain the security benefits by not turning it off for the entire user base, in a shared platform environment, when a subset of your users encounter it and perhaps try to persuade you to turn XCMD back on!

The NOXCMD option disables a number of SAS language features that allow the execution of operating system commands such as:

• the use of PIPE in the FILENAME statement (SAS documentation links for Windows and UNIX)
• the CALL SYSTEM routine
• the X command (SAS documentation links for Windows and UNIX)
• the %SYSEXEC macro statement
• the SYSTASK statement (SAS documentation links for Windows and UNIX)

The SAS documentation for NOXCMD can be found under its positive alternative, the XCMD system option. Here are links to the relevant documentation for Windows and UNIX.

We have become more familiar with NOXCMD in recent years because the the SASApp – Workspace Server, SASApp – Pooled Workspace Server and SASApp – Stored Process Server in SAS 9.2 installations commonly have the XCMD option disabled (i.e. NOXCMD). This is the default setting in newly installed SAS 9.2 deployments for its security benefits. To allow the general SAS user community (such as SAS Enterprise Guide users) to execute operating system commands on the servers, a SAS platform administrator has to make a conscious decision to enable XCMD, preferably after careful consideration of the potential security consequences ;). Here is a screenshot fragment showing where XCMD can be turned on in the server’s Launch Properties tab. You get to this tab using the SAS Management Console 9.2 Server Manager plug-in via the Advanced Options button on the Options tab in the server’s properties dialog.

While you are in the SAS Management Console, you might also notice that the SASMeta – Workspace Server is different in that it has XCMD enabled by default. Normal SAS users can’t use the SASMeta – Workspace Server because metadata access controls make it visible only to metadata administrators (members of the SAS Administrators group).

If you schedule SAS jobs to run in batch you might also want to check the NOXCMD status of the batch servers: SASApp – SAS DATA Step Batch Server, SASMeta – SAS DATA Step Batch Server and any others you may have. The XMCD/NOXCMD setting for these servers are specified not in metadata but in the batch server scripts. On Linux, my batch server scripts are in /usr/local/SAS/ebiedieg/Lev1/SASApp/BatchServer/sasbatch.sh and /usr/local/SAS/ebiedieg/Lev1/SASApp/BatchServer/sasbatch.sh. The SASApp one has -noxcmd whereas the SASMeta one has -xcmd. These are the default settings for batch server deployments in recent SAS 9.2 releases. If you have an older SAS 9.2 release (pre M2), you might find that the SASMeta one is also -noxcmd. The NOXCMD constrained SASMeta – SAS DATA Step Batch Server in older SAS 9.2 releases caused problems with scheduled metadata backups as described in SAS Problem Note 34923: A metadata backup that is scheduled to run by using the SAS DATA Step Batch Server might fail to copy the configuration files and the journal files

So what can you do if your security plan doesn’t allow you to enable XCMD for the general SAS user community, but some of your users, or batch processes, are failing to run operating system commands because of it? A couple of possible options include:

• using/suggesting native SAS language alternatives to operating system commands where possible;
• creating a new special purpose application server and associated workspace and/or stored process servers that are restricted in visibility (via metadata access controls) to a subset of trusted users/developers. There is a good example of this approach in Jim Fenton & Robert Ladd’s SAS Global Forum 2010 paper 311-2010: A Practical Approach to Securing a SAS® 9.2 Intelligence Platform Deployment

I’ll try to suggest some native SAS language alternatives to operating system commands in future blog posts. If you have any favourites yourself feel free to leave a comment.

I hope this post has helped you find out more about the NOXCMD option and that you don’t always have to turn it off at the first sign of trouble. Remember people tasked with managing security have a reputation to uphold: when it comes to security the first answer is almost always “no”, or perhaps the more pragmatic “no, but how about this alternative more secure method instead…” ;)