[Samba] Restricting samba subfolder acl changes to admin users

[Jeremy Allison]

On Fri, Oct 15, 2010 at 07:09:02AM -0400, suresh.kandukuru at emc.com wrote:
> Got it Volker . Thanks .
> 
> once final Q is ,I have admin user in NAS . for a share "test" , he has given write access to user "user1 " and  read access for a  subfolder -> "testsubdir" in share "test" .
> when user1 logged into share  "test",  he could not write into "testsubdir". obviously it is because he has read access on the folder an most restrictive access will be effective.
> 
> and the problem is since the user1 has write access to share , he is able to change the  read access on the sub folder by himself. why samba is allowing this ? since effectively user1 has read access on the sub folder "testsubdir" it should deny acl changes on that right?.


You are confusing write access on a share ACL, with write access on a
directory.

If a user only has read access on a share ACL, he will only be able
to read data on that share, no modifications to any files/folders or
ACLs will be allowed.

If a user has write access on a share ACL, then he can modify anything
inside that share that the underlying filesystem gives him rights to
do so (if you're using POSIX ACLs/permissions, not Windows ACLs).

So, when you complain that user1 can change the permissions on a sub
folder, look at the owner and permissions on that sub folder. If user1
has permission to write into the containing directory, he can modify
anything within it (according to the POSIX specs.).

Samba will override the POSIX permissions if "dos filemode" is set:
See the smb.conf man page:

       dos filemode (S)

           The default behavior in Samba is to provide UNIX-like behavior where only the owner of a
           file/directory is able to change the permissions on it. However, this behavior is often
           confusing to DOS/Windows users. Enabling this parameter allows a user who has write access to
           the file (by whatever means, including an ACL permission) to modify the permissions
           (including ACL) on it. Note that a user belonging to the group owning the file will not be
           allowed to change permissions if the group is only granted read access. Ownership of the
           file/directory may also be changed. Note that using the VFS modules acl_xattr or acl_tdb
           which store native Windows as meta-data will automatically turn this option on for any share
           for which they are loaded, as they require this option to emulate Windows ACLs correctly.

This might be what you're seeing.

If you want the client to only see Windows ACLs, look into the
"vfs objects = acl_xattr" option. There are a few bugs in it,
which I've currently fixed for 3.6.0 (and am preparing a back
port for the next 3.5.x release).

Jeremy.