Applying umask 007 to all (with possible exceptions)

[Dodecaphonic]

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?

[gwootton]

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.

[Dodecaphonic]

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.

[gwootton]

You could similarly try running the umask 007 command there and confirm it makes the expected change and that touch works as expected.

[Dodecaphonic]

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. 

[gwootton]

I guess that makes sense now that I think about it. X would fork a child process so running umask there wouldn't impact the sas session, only the forked process...that also means the change/setting to umask must be happen in the script (WorkspaceServer.sh, WorkspaceServer_usermods.sh, appservercontext_env(_usermods).sh, not in autoexec.

[gwootton]

Though when I did it using X it worked, so this might be something specific to AIX:

1? filename umask pipe "umask";
2? data _null_; infile umask; input; put _infile_; run;

NOTE: The infile UMASK is:
Pipe command="umask"

0002
...
3? x "umask 007";
4? data _null_; infile umask; input; put _infile_; run;

NOTE: The infile UMASK is:
Pipe command="umask"

0007

[Dodecaphonic]

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"...

[gwootton]

WorkspaceServer/autoexec_usermods.sas would apply only to the Workspace Server sessions, but if you set noxcmd you would not be able to set this via autoexec.

[Dodecaphonic]

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. 😐

[Tom]

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.