I have a qtree that's shared among NFS and CIFS clients. The security style is Unix.
If I set the umask to be 002, ie:
filer> cifs shares -change myshare -umask 2
Then the files created in the share via CIFS still have the *execute bits set*:
$ ls -al test.txt -rwxrwxr-x 1 user group 4 May 19 16:41 test.txt
That's not what I want; none of these files should really be executable.
I have read at least one thread in the list archives that suggest using a umask of 113, ie:
filer> cifs shares -change myshare -umask 113
This seems sketchy, but I gave it a try. Well, it works for files, but also omits the execute bits from newly-created *directories*:
$ ls -ald test* -rwxrwxr-x 1 user group 4 May 19 16:41 test.txt -rw-rw-r-- 1 user group 4 May 19 16:43 test2.txt drw-rw-r-- 2 user group 4096 May 19 16:48 test
And directories don't work so well in that case!
Am I missing something? Why should it not behave like the Unix umask command (with respect to directories)?
OnTap 7.2.5 if it matters.
Thanks,
On Tue, May 19, 2009 at 05:09:41PM -0400, Roy McMorran wrote:
If I set the umask to be 002, ie:
filer> cifs shares -change myshare -umask 2
Then the files created in the share via CIFS still have the *execute bits set*:
$ ls -al test.txt -rwxrwxr-x 1 user group 4 May 19 16:41 test.txt
That's not what I want; none of these files should really be
executable.
Since none of the execute bits are in '002', the umask can't affect executable bits being set.
A UNIX program would create a non-executable file by opening a file with O_CREAT and mode bits of 666. It would then expect the umask to trim it down (with your umask of 002, that woudl be to 664). So it's the program that's responsible for making it non-executable.
I don't think that same concept is used on windows, so default file creation is probably mode 777 (minus umask bits).
Am I missing something? Why should it not behave like the Unix umask command (with respect to directories)?
It looks to me like the umask is behaving as on UNIX, But the programs creating the files aren't.
Ed Wilts wrote:
Use the dir_umask option to set directory umasks.
Thanks to Ed, and also to Stetson Webster, Darren Dunham and Ned Harvey for your replies.
Cheers, -r
Roy McMorran wrote:
I have a qtree that's shared among NFS and CIFS clients. The security style is Unix.
If I set the umask to be 002, ie:
filer> cifs shares -change myshare -umask 2
Then the files created in the share via CIFS still have the *execute bits set*:
$ ls -al test.txt -rwxrwxr-x 1 user group 4 May 19 16:41 test.txt
That's not what I want; none of these files should really be executable.
I have read at least one thread in the list archives that suggest using a umask of 113, ie:
filer> cifs shares -change myshare -umask 113
This seems sketchy, but I gave it a try. Well, it works for files, but also omits the execute bits from newly-created *directories*:
$ ls -ald test* -rwxrwxr-x 1 user group 4 May 19 16:41 test.txt -rw-rw-r-- 1 user group 4 May 19 16:43 test2.txt drw-rw-r-- 2 user group 4096 May 19 16:48 test
And directories don't work so well in that case!
Am I missing something? Why should it not behave like the Unix umask command (with respect to directories)?
OnTap 7.2.5 if it matters.
Thanks,