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

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

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

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

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? ... View more

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

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

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

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

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

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