topic Re: Applying umask 007 to all (with possible exceptions) in Administration and Deployment

Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Thu, 19 Aug 2021 01:30:12 GMT

On a Unix SAS BI Platform, version 9.3, we are trying to change the umask of our users to 007. We were given this document as a reference: 38040 - Setting umask and ulimit values for SAS® sessions on UNIX and Linux

The first attempt was not successful. We tried several things, but not one of them seems to affect the umask for new user sessions.

Here are a few questions:

1. Is there a service or server that needs to be restarted in order for the changes to take effect?

2. One of the files we tried changing was WorkspaceServer/WorkspaceServer_usermods.sh. However, here is this file's content prior to making any change:

#!/bin/sh -p
#
# WorkspaceServer_usermods.sh
#
# This script extends WorkspaceServer.sh.  Add local environment variables
# to this file so they will be preserved.
#

USERMODS_OPTIONS=
umask 022

Changing the umask value to 007 did not work -- maybe because there is some service or server that needs to be restarted. Even if this is the case, given the current file's content, how do we go from this to this suggestion from the 38040 note (we will indeed need to specify a different umask for some users)?

if [ "$LOGNAME" = joe00001 ]
then
umask 022
fi

Where does the USERMODS_OPTIONS= line fit into this?

Thanks

Re: Applying umask 007 to all (with possible exceptions)

Sajid01 — Thu, 19 Aug 2021 12:16:12 GMT

The instructions in https://support.sas.com/kb/38/040.html are very clear.
For changes to take effect in workspace server, the umash option has to be in ObjectSpawner.sh.
Now about "Is there a service or server that needs to be restarted in order for the changes to take effect?". The answer is no.
Be aware that umask of 007 means a permission of 770.

Re: Applying umask 007 to all (with possible exceptions)

gwootton — Thu, 19 Aug 2021 12:16:59 GMT

Adding "umask 007" to the WorkspaceServer_usermods.sh script triggers that command to be run when a Workspace Server starts. This would not require any services be restarted as Workspace Servers are started on demand.

The USERMODS_OPTIONS= line allows you to add system options to the execution of the SAS executable as you would when running base SAS from the command line, which is not needed to set the umask.

Are the user sessions you are trying to control the umask for Workspace Server sessions (i.e. Enterprise Guide, SAS Studio sessions)?

Re: Applying umask 007 to all (with possible exceptions)

ronan — Thu, 19 Aug 2021 13:26:37 GMT

Following a umask of 007, a standard user creates a file with 660 - rw- rw- --- permission profile as required by the default permissions at creation step. See for Linux https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_managing-file-permissions_configuring-basic-system-settings#user-file-creation-mode-mask_assembly_managing-file-permissions

Following the same umask, a directory is created with 770 (rwx rwx ---) permission profile.

It's standard security on Unix/Linux not to grant execution permission by default to a file, it must be set explicitly unless you are root.

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Thu, 19 Aug 2021 17:03:56 GMT

They might be clear, but they just don't seem to work. We did try modifyinng ObjectSpawner_usermods.sh, which is called by Object_Spawner.sh.

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Thu, 19 Aug 2021 17:06:26 GMT

The question is not about which umask to use, but thanks for your input.

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Thu, 19 Aug 2021 17:14:39 GMT

Hi Greg,

That's exactly it. We tried changing the umask in both:

WorkspaceServer_usermods.sh
ObjectSpawner_usermods.sh

...and the umask remains unaffected in new sessions. I'm thinking ObjectSpawner.sh should be tried next, althoough I'm not exactly sure where to include the umask instruction.

For the USERMODS_OPTIONS= line, should we just remove it then?

Thanks

Re: Applying umask 007 to all (with possible exceptions)

gwootton — Thu, 19 Aug 2021 18:56:29 GMT

If this is from Enterprise Guide / SAS Studio sessions, I would expect adding the umask command to WorkspaceServer_usermods.sh would be sufficient. How are you determining this is not working?

You could try running WorkspaceServer.sh -nodms to start a terminal session and then something to create a file, as this could be getting modified by file system options on the folder where files are being created.

Having USERMODS_OPTIONS= in WorkspaceServer_usermods.sh should have no bearing on this, so you can leave it as is.

Re: Applying umask 007 to all (with possible exceptions)

gwootton — Thu, 19 Aug 2021 18:59:48 GMT

[sas@trcv003 WorkspaceServer]$ umask
0002
[sas@trcv003 WorkspaceServer]$ ./WorkspaceServer.sh -nodms -nonews
NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. 
...
NOTE: AUTOEXEC processing completed.

  1? x "touch /tmp/testfile";
  2? endsas;
...   
[sas@trcv003 WorkspaceServer]$ ls -l /tmp/testfile
-rw-rw-r-- 1 sas sas 0 Aug 19 14:56 /tmp/testfile
[sas@trcv003 WorkspaceServer]$ echo "umask 007" >> WorkspaceServer_usermods.sh 
[sas@trcv003 WorkspaceServer]$ ./WorkspaceServer.sh -nodms -nonews
NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA. 
...
  1? x "touch /tmp/testfile2";
  2? endsas;
...
[sas@trcv003 WorkspaceServer]$ ls -l /tmp/testfile2
-rw-rw---- 1 sas sas 0 Aug 19 14:57 /tmp/testfile2
[sas@trcv003 WorkspaceServer]$

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Thu, 19 Aug 2021 19:26:15 GMT

Hi Greg,

Yes "touch" is what I used to test it... Great idea to try running WorkspaceServer from terminal. About that though, do you know if there is a command line option that would prevent automatic library assignments? I launched it once and had many "bad username/password"; not sure why this is, but I sure don't want to be locked out from data sources by doing repeated tests!

Thanks again

Re: Applying umask 007 to all (with possible exceptions)

gwootton — Thu, 19 Aug 2021 19:32:15 GMT

You could add a dummy context for the metaautoresources option to prevent pre-assigned libraries from assigning. i.e. "-metaautoresources foo"

If you are using the touch command to test, you may want to run a getfacl on the path you are trying to store the file to ensure ACLs are not modifying the mask.

https://linux.die.net/man/1/setfacl

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Thu, 19 Aug 2021 20:08:12 GMT

Ok, I confirm that no matter the value I put in WorkspaceServer_usermods.sh, it is not taken into account. The files created with 'touch' systematically have -rw-rw-r-- permissions. This would corresponding to umask=002 if I'm not mistaken, but this 002 is neither the default umask on the Unix system, nor the default in WorkspaceServer_usermods.sh.

Just to recap, here's what I did:

#!/bin/sh -p
#
# WorkspaceServer_usermods.sh
#
# This script extends WorkspaceServer.sh.  Add local environment variables
# to this file so they will be preserved.
#

USERMODS_OPTIONS=

if [ "$LOGNAME" = myuser ]
then
        echo "Setting umask 007"  # to make sure the code is included -- it is
        umask 007
else
        umask 022
fi

I also tried without conditions, giving umask 007 for everyone for a brief moment, but it still didn't change a thing.

So something else is interfering somehow... setfacl is not a command that is available on this installation (Aix 6.1). Not sure if that rules out the ACL avenue though...

Re: Applying umask 007 to all (with possible exceptions)

gwootton — Thu, 19 Aug 2021 21:06:39 GMT

If you do these commands outside of the Workspace Server does it behave as expected (i.e. umask 007; touch somefile)?

The AIX ACL commands are acledit and aclget it looks like.

https://www.ibm.com/docs/en/aix/7.1?topic=acledit-command

https://www.ibm.com/docs/en/aix/7.1?topic=aclget-command

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Thu, 19 Aug 2021 21:49:47 GMT

Yes the umask / touch commands behave as expected in a SSH session.

If I type aclget . in my home directory, I get:

*
* ACL_type AIXC
*
attributes:
base permissions
owner(myuser): rwx
group(staff): --x
others: ---
extended permissions
disabled

Not sure what to look for next... thanks for your guidance!

EDIT: The active umask in the SAS session appears to be 003, not 002, since a directory created with x mkdir has permissions drwxrwxr--.

Re: Applying umask 007 to all (with possible exceptions)

gwootton — Fri, 20 Aug 2021 12:13:04 GMT

If its behaving as expected in an SSH session it's probably not an ACL issue. Do you have another umask command being called after the WorkspaceServer_usermods.sh is sourced (maybe in autoexec)? You could add the ECHOAUTO option when running WorkspaceServer.sh to see what is being run by autoexec.

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Fri, 20 Aug 2021 16:22:03 GMT

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?

Re: Applying umask 007 to all (with possible exceptions)

gwootton — Fri, 20 Aug 2021 16:23:43 GMT

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.

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Fri, 20 Aug 2021 16:31:14 GMT

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.

Re: Applying umask 007 to all (with possible exceptions)

gwootton — Fri, 20 Aug 2021 17:02:20 GMT

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

Re: Applying umask 007 to all (with possible exceptions)

Dodecaphonic — Fri, 20 Aug 2021 17:53:02 GMT

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.