cifs share umask for a unix qtree

[Roy McMorran]

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,

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@...

[A Darren Dunham]

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.

--
Darren

[Roy McMorran]

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

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmorran@...