What is determining the UMASK for a scheduled SAS job? SAS? Platform LSF?

[chawkins]

LOOOONG time lurker, first time poster.
 
We run SAS 9.4 on a Linux box and use Platform LSF to manage our scheduled jobs. Permissions are being set on datasets created by scheduled jobs with a different UMASK (0022) than when I create them in EG (0002), even though my user owns the process for the scheduled job. We keep running into this when a dataset is first created by the scheduled job because group write privileges are missing and we have to manually update the permissions.
 
I can't find anywhere in the Config directory where umask is being set explicitly by the invoked SAS session. I also can't find anywere that's explicitly setting it in the LSF directories. I suspect it is getting the UMASK from an environment variable somewhere or by referencing a profile that isn't of the user themselves. 
 
Can anyone help me unmask the masked man who is masking the UMASK?
 
Chris
Befuddled Data Monkey

[jklaverstijn · Accepted solution]

Hi,

There are several places to do this, depending on the scope of the setting you want. For batch jobs I would suggest adding the umask to the scriptfile <Configdir>/Lev{n}/SASApp/BatchServer/sasbatch_usermods.sh. Depending on your deployment your servername may be different from SASApp. I hope you get the idea.

In general most configuration files have a "usermods" version that allows you to separate the SAS owned logic from your own. The usermods files will never be touched by updates from SAS.

Another common place to add code to the scripting would be <Configdir>/Lev{n}evel_env_usermods.sh. This has a much broader scope than the one mentioned above.

Hope this helps,

- Jan.

[jklaverstijn]

As a quick addition:

SAS has a separate system option called WORKPERMS that determines the protection mode for work datasets. This can be set in the sasv9_usermods.cfg file.

[alexal]

@jklaverstijn,

An option WORKPERMS does apply only to datasets in SAS Work library.

@chawkins,

I just sent you a message in the track.

[chawkins]

Thanks @jklaverstijn

That definitely makes sense for explicitly overriding whatever it is inheriting when the job gets submitted.

I'm compulsive about trying to run down ghosts in the machine, so I'd still like to know where the UMASK is coming from to begin with (not asking you that. I'll just continue my vision quest at lower priority), particularly so our server admins can figure out exactly how things work and can document them for future installs. I went back to our 9.3 installation and we don't have anything in the usermods file there, and we don't experience the same discrepancies, so it's still a bit of a mystery.

Chris

[chawkins]

Thanks Jan. 

Adding the umask explicitly to the sasbatch_usermods.sh file does eliminate the discrepancies for new file/directory creation.

I'm still curious about the cause of the discrepancy, but we'll root around on our dev server for that answer.

Chris

[JuanS_OCS]

Hello @chawkins,

excellent question I must say. If you have a track open with @alexal, please don't mind to keep it up with him, also @jklaverstijn is pin pointing into the right direction.

Perhaps I won't add anything new, or clarity, but I will give it a try to support them and to support you.

This SAS Note http://support.sas.com/kb/38/040.html helps to explain and gives advise about the umask settings in SAS sessions.

If I understand correctly, there is some difference between the umask with EG sessions and Batch jobs.

For SAS this means that EG always runs on the Workspace Server (SASApp/WorkspaceServer) and on the name of the user who launches EG; and for Batch jobs, those sessions will be using the BatchServer (SASApp/BatchServer) and will be sent to LSF to execute the job, on the name of the one scheduler user.

One of those directories' usermods file might have a different umask setting. But I also consider that the linux user profiles might contain the umask setting. Perhaps it is worth to check both usermods files and also the profile file of the scheduler user and one key EG user.

To wrap it up, LSF does not provide any additional setting for umak settings. Please check the LSF Security Guide https://support.sas.com/rnd/scalability/platform/PSS5.1/lsf7.05_security.pdf on page 7

Job data files Jobs running in the LSF cluster inherit the environment from the user that submitted the job. Work files and output files are created based on the file permissions environment of the user (such as umask in POSIX environments). LSF does not provide additional security to these files. Therefore, to increase the security of work and output data, you need update the security of your hosts and file system according to the operating systems on your hosts.

[JuanS_OCS]

Hello @chawkins,

since your question was posted one week ago, I am wondering if you could have your question answered and given a solution, or you are still looking for information. And, of course, if you have your solution, please help us and other users marking it as solution, or adding a short description on what was your solution.

Thank you in advance!

Kind regards,

Juan

[chawkins]

Juan,

Thanks for the reminder on etiquette. The noob abides and marked an above post as the solution. We added umask 0002 explictly to the sasbatch_usermods.sh script.

Just to follow up on what you've said above, the curious thing here is that the Linux user I run things as in enterprise guide is the user that owns the process for the scheduled job and thus the files that are created by it. But it's clearly deferring to something else for how to assign the permissions.

So the ghost in the machine is still haunting the halls, but no one will notice but me. Such is the tortured life of those behind the scenes.

Thanks again to you and everyone who took the time to help with my education.

Chris

[Kurt_Bremser]

The inheritance of permissions can ba a curious thing. If you want to investigate further, consider this:

The Object Spawner ist started from the inittab with a su - sasinstalluser. So it inherits all settings of the install user. These permission settings are then inherited throughout its children, even when the current userid is set to yours when the spawner finally runs the shell script that starts the workspace server. It does not completely do the equivalent of a su -, sadly.