Nothing particular showed up when I added the ECHOAUTO parameter. With find, I searched in .sh, .sas, and .cfg files for the string "umask", in everything under /sas. I used for instance (for .sh files):
find /sas -name '*.sh' -exec grep umask {} +
I found nothing in the usual setup files. I did however find some results in other shell scripts. Here for instance, the default umask is replaced by user / group / other umask definition:
./SASHome/InstallMisc/cleanup.sh:# set_umask
./SASHome/InstallMisc/cleanup.sh:# Set the umask according to the rules defined in the data.
./SASHome/InstallMisc/cleanup.sh:set_umask () {
./SASHome/InstallMisc/cleanup.sh: mask=`umask`
./SASHome/InstallMisc/cleanup.sh: if [ "$umask_user" ] ; then
./SASHome/InstallMisc/cleanup.sh: mask=`set -f ; echo $mask | sed "s/[0-7]\([0-7][0-7]\)$/$umask_user\1/"`
./SASHome/InstallMisc/cleanup.sh: if [ "$umask_group" ] ; then
./SASHome/InstallMisc/cleanup.sh: mask=`set -f ; echo $mask | sed "s/[0-7]\([0-7]\)$/$umask_group\1/"`
./SASHome/InstallMisc/cleanup.sh: if [ "$umask_other" ] ; then
./SASHome/InstallMisc/cleanup.sh: mask=`set -f ; echo $mask | sed "s/[0-7]$/$umask_other/"`
./SASHome/InstallMisc/cleanup.sh: umask $mask
./SASHome/InstallMisc/cleanup.sh:# Set the umask
./SASHome/InstallMisc/cleanup.sh:set_umask
Not sure where these alternate umasks would be defined. (We have some custom settings in /sas/SASHome/SASFoundation/9.3/misc/rstropts, but nothing pertaining to umask).
There are qui a few files showing something along those lines. I have no idea whether these files are relevant at all. Most are in software/lsf and software/pm. I could send you all results by other means if you think it's relevant?
Can you run the "umask" command within SAS and confirm it is set incorrectly?
$ ./WorkspaceServer.sh -nonews -nodms -metaautoresources foo NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. ... NOTE: AUTOEXEC processing completed. 1? filename umask pipe "umask"; 2? data _null_; 3? infile umask; 4? input; 5? put _infile_; 6? run; NOTE: The infile UMASK is: Pipe command="umask" 0002 NOTE: 1 record was read from the infile UMASK. ... 7? endsas;
Any umask change from where it is being set in WorkspaceServer_usermods.sh would have to happen after that is sourced, so I wouldn't expect anything in SASHome, LSF or PM to play a role.
You may wish to engage SAS Technical Support.
It is indeed 003 as I suspected:
NOTE: AUTOEXEC processing beginning; file is /sas/Config/Lev1/SASCompute1/WorkspaceServer/autoexec.sas. NOTE: AUTOEXEC processing completed. 1? filename umask pipe "umask"; 2? data _null_; 3? infile umask; 4? input; 5? put _infile_; 6? run; NOTE: The infile UMASK is: Pipe command="umask" 0003 NOTE: 1 record was read from the infile UMASK. The minimum record length was 4. The maximum record length was 4. NOTE: DATA statement used (Total process time): real time 14.86 seconds cpu time 0.00 seconds
I will open a ticket. Thanks.
Hi Gregg,
This is interesting. First I submit this:
1? filename umask pipe "umask 007; umask"; 2? data _null_; 3? infile umask; 4? input; 5? put _infile_; 6? run; NOTE: The infile UMASK is: Pipe command="umask 007; umask" 0007
Right after, in the same session:
x 'touch ~/test-umask-1';
The file has permissions that reflect the initial umask (003):
-rw-rw-r-- test-umask-1
Then, I do this:
1? filename umask pipe "umask 007; touch ~/test-umask-2"; 2? data _null_; 3? infile umask; 4? input; 5? put _infile_; 6? run;
...and the umask value is now honnored:
-rw-rw---- test-umask-2
Not sure what this tells us though.
Ha! It does work if umask is set via x. So the sub-process happens for the filename/pipe, but not for x, it appears.
If we can specify umask in autoexec, and block system commands with noxcmd, in theory that should work fine... I'll try doing that. The next question will be "which autoexec"...
I see. It'll have to be something else then.
One of your colleagues at tech support suggested I check in SASFoundation/9.3/bin/sasenv_local, and that was it. It contained the umask command (u=rwx,g=rwx,o=r, which corresponds to 003).
I couldn't see it before because when I used find + grep, I searched only the files having extensions .sh, .sas and .cfg. 😐
That is probably the first place you should have looked. The little I know about modern SAS installation is that you should put your "local" modifications into the "local" files to avoid them getting wiped out by any patches or updates.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.