| This post was kindly contributed by The SAS Dummy - go there to comment and to read the full post. |
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 Gude?
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.)
| This post was kindly contributed by The SAS Dummy - go there to comment and to read the full post. |