Applying umask 007 to all (with possible exceptions)

[Dodecaphonic]

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

[Sajid01]

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. 

[ronan]

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

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. 

[Dodecaphonic]

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

[Dodecaphonic]

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.

[gwootton]

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)?

[Dodecaphonic]

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

[gwootton]

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.

[gwootton]

[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]$ 

[Dodecaphonic]

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

[gwootton]

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

[Dodecaphonic]

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

[gwootton]

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

[Dodecaphonic]

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

[gwootton]

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.