Failure Analysis of Samba (4/23) with NT

Jeremy Allison jeremy at
Wed May 2 21:08:27 GMT 2001

John Trostel wrote:
> Looks like it fixed the problem with Dr. Watson alright!
> Now, it's on to figuring out why ACLs aren't being changed correctly.  When you
> are asking exactly how and what permissions people are changing on the NT side
> when it screws up (apparently) on the other (Linux/SUN/etc?) side.  I know what
> I am doing....
> set file up with rwxrwxrwx and acl as the same [u::rwx,g::rwx,o::rwx]
> click on file/Properties/Security
> click on the permissions button
>         normal unix permissions are still rwxrwxrwx
>         ACLs are u::rwx,g::rwx,o::rwx
> click OK in permissions dialog box
> click on the permissions button again!
>         NOW permissions are reset to rwxr--r--
>         and ACLs are now [o::r--,g::r--,u::rwx,m::rwx]
> Time to go home and get some dinner and a brew...

Ok - I know what's happening here....

I added code in Samba between 2.2.0 tarball and 2.2CVS
to enforce the Samba "create mask, force create mode"
parameters in Samba on a ACL set call.

By default, create mask is set to 744 - do you see the
simularity here.... :-) :-).

What is happening is when you click "ok" - you're requesting
that Samba set the ACL back on the file. Samba masks off
the "new" requested permissions (777) with the create mask
(744) and bingo - you have the permissions you see.

Hmmm. I should probably add a parameter to make the enforcing
of these masks optional. The issue is that admins set these
masks to enforce policies on a share (ie. all files must have
group read/write set) and having ACLs ignore the mask/force mode
parameters allows users to violate these policies by setting

Do you have any ideas on the best default to set for 2.2.1 ?
I'm CC:ing this to samba-technical to get more feedback.


Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.

More information about the samba-technical mailing list