The below outlined issue is due to the SGE environment. SGE hard codes
the umask into its source rather than propagating the user's umask to
jobs. The relevant Grid Engine mailing list post is here:
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=88691
I'm looking into how I might modify the fsl_sub script to propagate
the user's umask correctly.
-james
On Jun 8, 2009, at 9:50 AM, James Kyle wrote:
> Thank you for your response, Mark. My apologies for the delay in
> response, we are also transitioning clusters at this time.
>>
>
>> I cannot see how this is possible as we do not do anything
>> unusual with permissions anywhere in FSL. All we do is
>> write files with the standard methods in C++, sh scripts and
>> tcl scripts.
> I thought it may be related to the spawning of new shells in an SGE
> environment such that the user set umask might be lost.
>>
>> Can you give us a specific example to try?
> Sure, I've attached a script file that provides the output of a fsl
> session I ran. I also displayed the pre and post umask values as
> well as the permissions on the resulting feat output.
> <typescript>
>
>
>> We do this kind of thing all the time and it is fine.
>> Have you double-checked that it is not a sticky permission
>> associated with your directory that is overruling your
>> umask permissions?
> I checked these, we're seeing the behavior across all users. We
> never had issues before, but I configured our old server to use
> ACL's that would override any niggling permission problems.
>>
>> If you can find a specific case and let us know about it we
>> will try and help.
> I'll do my best. :)
>
>> Tell us both what commands you are running,
> $ feat design.fsf
>
>> what your umask is
> umask = 007
>> and an ls -la of the directory that you are
>> writing to (as well as how that file system is mounted - NFS, etc.)
> NFS, the attached script show's the full output, but here's the
> specific folder permissions for all directories from current then up
> to root (/)
> login4:/u/home9/FMRI/mscohen/data/jkyle {1002}$ ls -ld .
> drwx------ 8 jkyle mscohen 2048 2009-06-05 11:38 .
> login4:/u/home9/FMRI/mscohen/data/jkyle {1003}$ ls -ld ../
> drwxrwx--- 8 jkyle mscohen 2048 2009-05-19 14:07 ../
> login4:/u/home9/FMRI/mscohen/data/jkyle {1004}$ ls -ld ../../
> drwxr-xr-x 20 root root 2048 2009-04-14 14:55 ../../
> login4:/u/home9/FMRI/mscohen/data/jkyle {1005}$ ls -ld ../../../
> drwxr-xr-x 8 root root 0 2009-06-05 11:38 ../../../
> login4:/u/home9/FMRI/mscohen/data/jkyle {1006}$ ls -ld ../../../../
> drwxr-xr-x 10 root root 0 2009-06-05 11:46 ../../../../
> login4:/u/home9/FMRI/mscohen/data/jkyle {1007}$ ls -ld ../../../../../
>
>
>> Hopefully we can figure out what is wrong.
>
> Thank you for your efforts on this.
>
> James Kyle
|