One of the often-cited side effects of moving from "Base SAS" (SAS on your PC, or Display Manager) to SAS Enterprise Guide is the loss of "X" command privileges -- that is, the ability for your SAS programs to invoke other programs via the operating system shell. We call this "XCMD" thanks to the SAS system option that controls it, but in practice this means that SYSTASK, FILENAME PIPE, and similar invocations no longer work.
These statements would have continued to work from SAS Enterprise Guide but for one decision that SAS R&D made back before the turn of the century (yes, 1999): by default, SAS workspace servers are configured with NOXCMD in place. (That decision applied even when using SAS Enterprise Guide and your local SAS install - a silly restriction that has been lifted in SAS 9.3.)
SAS workspace servers (and their multiuser cousins, SAS stored process servers) can run all types of SAS programs on the user's behalf, where the user might not be a savvy SAS programmer or at all familiar with the operating environment. For example: today an analyst might click a button in Excel and have SAS-produced results magically appear in his spreadsheet. Should that guy have the ability (inadvertently or purposefully) to submit a shell command where SAS is running? SAS R&D erred on the side of the conservative IT admin and said "nope".
Initially, it was difficult to override this restriction. The only way to allow the XCMD operations was to specify a less-than-documented double-negative option -NONOXCMD. But today it's much easier to throw the switch back the other way, implying that allowing shell commands in a SAS workspace session is indeed a sanctioned configuration. Paul Homes has a very good blog post on the process for toggling "Allow XCMD" - it's a simple checkbox in SAS Management Console.
So if you're a SAS administrator who is faced with the plea from users to "please allow XCMD!", how should you decide whether to grant the request? (Don't hide behind the excuse that NOXCMD must be the default for a reason -- often, the default settings aren't good enough for every situation.)
Admins need to know that there is nothing nefarious about SAS processes that make them especially risky. The SAS executive does not run as root or as some kind of super user -- at least not in the traditional SAS workspace session, which runs under the user account of the authenticated user.
I believe that the decision to enable XCMD can be made at most sites by following a simple questionnaire:
1. Do your SAS users have user accounts on the host server system, and are those accounts used when connecting via SAS Enterprise Guide?
2. If YES, can those users SSH into (or otherwise terminal into) the host server and run commands?
If the answer is YES to both, then the users already can technically do what they need and the NOXCMD is an artificial, inconvenient barrier. There is no additional risk to toggle it, so why not make your users happy?
If the answer is NO to 1 or 2, then you may need to vet the user and/or his task further before taking action. It's an opportunity for further conversation. (Hey, don't laugh! Some SAS admins do talk to users!)
There are scenarios where admins should proceed with more caution. For example, what if your SAS workspace is configured to use a group account, and not that of the person using SAS Enterprise Guide? Or what about SAS stored process servers, which run under system account (like sassrv)? If your configuration doesn't guarantee that any SAS-launched shell process will run with the end user's identity (and therefore, with his privileges and accountability), then it's wise to be more conservative.
None of us want to see a SAS-related process get blamed for some system catastrophe. But good information, and perhaps a bit of onsite testing, should drive the decision.
(This post was inspired by this thread on SAS-L.)
14 Comments
Thanks for your post, Chris. Just wanted to let you know you have a small typo - 1. Do your SAS users have user accounts on the host server system, and are those accounts used when connecting via SAS Enterprise Gude? (Gude should be Guide).
Looking forward to the next post!
Jeff
Thanks Jeff - fixed that!
Hi Chris,
Thanks for mentioning my blog!
That's a good idea to use a questionnaire to consider the sensibility of restricting XCMD for users that might have the ability to execute shell commands via alternative login mechanisms anyway.
If the answer to that question is yes for some users and no for others, and opening up XCMD access to everyone is not an appropriate/available choice for the organization, there are also ways to provide limited XCMD access for a limited subset of users too.
Jim Fenton & Robert Ladd’s SAS Global Forum 2010 paper 311-2010: A Practical Approach to Securing a SAS® 9.2 Intelligence Platform Deployment presents an approach using differently configured servers with access controls determining which one you have access to.
Another option, on UNIX platforms, is to use the restricted options feature with standard workspace servers to tailor the configuration of a SAS process dynamically based on the user or group that is launching it. There's more info on this in another blog post: SAS Restricted Options on UNIX.
Cheers
Paul
Paul, thanks for the excellent references! You're correct: XCMD doesn't have to be "all on" or "all off". SAS administrators have many options available, and these referenced papers show how you can give your users the flexibility that they need without compromising security or system stability.
The Restricted Options feature is no longer a unique feature of SAS Unix; it is officially available for SAS Windows too starting with version 9.3 (but it already works with 9.2 ;-)
See page 7 :
http://support.sas.com/documentation/installcenter/en/ikfdtnwx6cg/64433/PDF/default/config.pdf
The only "restriction" that still applies for Windows is the ability to define a restriction list at Group process level for SAS Unix: for Windows, scopes are only twofold : global / per user basis.
The case for discussing with the users as regards their XCMD personal requirements is very strong from my experience; sometimes - if not always - you might make then adopt as best practice pure SAS code instead of the nefarious System Commands (unstable, difficult to debug, OS-dependent or even shell-dependent etc.).
Ronan
Ronan, thanks for the info and good points. I find that many SAS jobs contain code that was crafted years (or decades) ago, and they might use constructs that could benefit from "modernization". It never seems like a convenient time for such introspection, but sometimes a change in process (like going from PC SAS to a central SAS server) will force the activity.
Chris,
I have a Teradata BIGINIT issue (Problem Note 39831) that can be resolved with an environment variable. I do not want to make a global change. Is there any way to do this without the X command. We have setup our metadata with multiple workspace servers, one with NOXCMD and the other with. We then use group permissions to allow X as needed. As one of those SAS admins that actually talks to users, I also like to keep them from shooting themselves in the foot.
{;o)
Mark, I don't know whether you can set an environment variable "on the fly" and affect the TERADATA connection like this. I suggest working with SAS Technical Support (as you probably already are) for the best solution.
Pingback: SAS trick: get the LIBNAME statement to create folders for you - The SAS Dummy
Pingback: Twelve advantages to calling R from the SAS/IML language - The DO Loop
Pingback: Using SAS and ODS PACKAGE to create ZIP files - The SAS Dummy
Pingback: Fencing in your SAS users with LOCKDOWN - The SAS Dummy
Pingback: Twelve advantages to calling R from the SAS/IML language - The DO Loop
Pingback: List the contents of your ZIP and gz files using SAS - The SAS Dummy