09-18-2015 09:42 AM
I use Enterprise Guide with SAS 9.4 on a server and the X command (thankfully) enabled. But a few weeks ago, I ran into an issue with the X command, EG would freeze and wouldn't exit normally.
I tracked this down to a configuration program that connected a network drive using
x "net use p: \\server\share";
This connected a network drive for my personal use, based on my userid. A few days earlier, my userid had changed and what seems to have happened is that the Windows server sent a prompt whether the "persistent" drive letter should be attached to a different network share. That prompt went to the SAS server console, it never reached me and of course I couldn't respond, Disabling the X command for this drive letter fixed the problem but I wanted to be able to safely use that drive.
The solution I'm using now is to use an infile statement with a pipe option:
data _null_; infile "net use /y p: \\nlwagefs00\private\&sysuserid" pipe; input; put _infile_; run;
(This is based on a post to SAS-L by Tom Abernathy, thread "SAS loses focus on X/call system invocation")
This method writes the results of the shell command to the SAS log. If anything went wrong, you can read it there. I've tested it with a mis-spelled share name and in that case, the log will report "Stderr output: System error 53 has occurred. The network path was not found."
Perhaps others will find this method useful as well. I'm interested to know if this construction could fail in some way or another. I'd also like to know if there's any further documention on this method. Googling for "_null_", "pipe", "infile" doesn't produce helpful results. The SAS 9.4 help for the infile statement states "PIPE: specifies an unnamed pipe. Note: Some operating environments do not support pipes." Not very helpful.
09-18-2015 09:47 AM
I am not entirely sure I see why your setting up Windows drive letter mappings to network resources in code. Why do you not do this via Windows, or have your helpdesk team set this drive up ready to use.
09-21-2015 06:11 AM
The drive letters aren't configured on the server, that's why I want to map them in a configuration program. Mapping the drive letters is convenient when programming, that way I can copy an address from Windows Explorer and paste it in my programs. I find it also makes things more readable.
The larger issue is how to deal with shell commands that fail or cause SAS to hang by prompting for user input. An input statement with a pipe option can deal with this. Does anyone know any documentation on this?
09-21-2015 07:16 AM
Well, the pricipal behind it that users should not be piping out to the underlying system. A lot of companies will switch this functionality off by default. There are a lot of security reason why this would be the case, and functional as well. If you need to use a UNC in a program, then put it in a macro variable. This can be in either your program, or your autoexec.sas. E.g.
Alternatively get your infrastrcuture people to setup the account with the correct mappings. For us, when SAS starts up the drives are auto mounted to drive letters, but this is an infrastructure problem and so should be IT or your infrastructure team.
09-21-2015 03:29 PM
Sorry to disagree RW9. The Xcmd has really nothing to do wiht security reasons. Yes security people are coming in wiht a checklist users are not allow to use a shell, the only acceptable working approach is having it all in predefined fixed menus made by it-staf.
Is that the requiere policiy, by sure not. iso/iec 27002:2013
9.4.4 Use of privileged utility programs
The use of utility programs that might be capable of overriding system and application controls should be restricted and tightly controlled. -- Implementation guidance ---
The following guidelines for the use of utility programs that might be capable of overriding system and application controls should be considered:
a) use of identification, authentication and authorization procedures for utility programs;
b) segregation of utility programs from applications software;
c) limitation of the use of utility programs to the minimum practical number of trusted, authorized users (see 9.2.3);
d) authorization for ad hoc use of utility programs;
e) limitation of the availability of utility programs, e.g. for the duration of an authorized change;
f) logging of all use of utility programs;
g) defining and documenting of authorization levels for utility programs;
h) removal or disabling of all unnecessary utility programs;
i) not making utility programs available to users who have access to applications on systems where segregation of duties is required.
See the joke. SAS itself is doing that weird things (sasauth identification shared accounts) it is a hard job to get it accepted as a compliant tool for data-analytics. Datascience guys thar are not using predefined menus of IT guys? They aer dangerous and should be blocked. It would be far better for SAS to get compliant wiht these guidelines and get accepted the OS controls are needing to work on by the OS-admins. That is similar wiht the R usage for data science,
09-21-2015 07:36 AM
It sounds like you're on the correct path (so to speak) with the solutions so far.
Mapped drives don't work the same from EG because your connection to the SAS server doesn't run through the normal interactive login routines that include operations like mapped drives. Your session is actually logging in more like a batch job in Windows, not as a full terminal session.
UNC paths can work as long as your remote server can access those network resources on your behalf (using a privilege called Trusted for Delegation, which it sounds like you have already working properly).
09-21-2015 04:21 PM
If the only reason to do drive mappings is to be able to copy and paste mappings from Windows Explorer to your programs, then you can do exactly the same thing with UNC paths and save yourself a lot of hassle at the same time - I never use drive mappings and exclusively use UNCs. If you use UNCs in your code, then these programs will run anywhere on any PC or server without configuring mappings all the time.
Try this in Windows Explorer: \\SASServer\SASdir1\SASdir2 (substitute your own directories here).
09-22-2015 02:11 AM
I have also had some luck with similar issues by making sure to add the -noterminal option on the command line when SAS is launched to run in the background. That should have a similar effect of letting the sub shell understand that there is no one there to respond to prompts so it does not generate the prompts.
09-23-2015 01:57 AM
This is more about understanding what is happening at the OS level (Windows) than fucntionality at the user interface.
ChrisH made already a nice reference to the SSO part. That ones refers to the Windows Privileges.
If the workspace server runs on Windows, give this privilege to the account under which the object spawner runs. By default, the spawner runs as a service under the local system account, so the computer account for spawner's host needs the privilege.
That is bad securiyt approach really to be avoided. The reason to avoid is by common guidelines like: System Services MS technet
"Local System account. The Local System account is a powerful account that has full access to the computer and acts as the computer on the network. If a service uses the Local System account to log on to a domain controller, that service has access to the entire domain. Some services are configured by default to use the Local System account, and this should not be changed. The Local System account does not have a user-accessible password."
"In previous versions of Windows, system services commonly ran by using the Local System account, the most powerful account on the system. This made such services attractive targets for creators of malicious software such as viruses. Ideally, service developers should limit their damage potential by developing services to run using a lower-privilege account such as Local Service or Network Service. However, many services require at least some privileges that only Local System supports. The all-or-nothing model that was used in versions earlier than Windows Vista meant that a service that required any Local System privileges had to also include all other Local System privileges. This often meant including privileges that the service did not require, creating an unnecessarily high damage potential."
With SANS and at other (malware hardening reated) you can find a lot on service accounts. The best thing would to do wirh SAS is using dedciated service accoutns. securing-windows-service-accounts-107116 SANS. Why SAS is missing this is shameful, as of the Vista era (2005) this is known. Anyway changeing the lcoal system accoutn securyt settingsfor advice is as bad as using internet wihtoud malware or intrusion detection
Having the SAS processes being childs of the Object Spawner process (bact jobs) you can not get resources out of that context (no keybaord no screen). Programs relying on those screen/keyboard interfaces will crash. A headless or noterminal can help to avoid that. Trying to becom e a windows admin will fail. This is quite different on a local desktop as it is not using the spawner.