[Samba] Restricting samba subfolder acl changes to admin users

suresh.kandukuru at emc.com suresh.kandukuru at emc.com
Sun Oct 17 22:12:55 MDT 2010

Thanks Jeremy and Volker. Clarified  some of points.still little bit confusion for me.
so, in summary if a user can change ACL, if he has write acess on the share and the ownership on subfolders / files inside it.

here is is my test.

1) created share "test" , given write access to it for "admin", "user1" users.

2) connected to share with admin user and created sub folder "test_subfldr" in it. and given read access to user1 user
output of getfacl
root at storage:/mnt/soho_storage/samba/shares/SP0/test# getfacl test_subfldr/
# file: test_subfldr/
# owner: admin
# group: users

root at storage:/mnt/soho_storage/samba/shares/SP0/test#
4) connected to test share with user1 , could not write into test_subfldr. and user1 has changed  acl settings  on test_subfldr to write access .
why samba is allowing this? Though user1 has write access to share , he is not the  owner of test_subfldr/.(admin is the owner for this) . user1 effectivly has  read access on the test_subfldr.

attached smb.conf  for your reference.


-----Original Message-----
From: Jeremy Allison [mailto:jra at samba.org] 
Sent: Saturday, October 16, 2010 6:28 AM
To: Kandukuru, Suresh
Cc: Volker.Lendecke at SerNet.DE; samba at lists.samba.org; jra at samba.org
Subject: Re: [Samba] Restricting samba subfolder acl changes to admin users

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

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).


More information about the samba mailing list