SAMBA file rights and ACLs

Making the best out of two worlds

© 2010-2013 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later

Index

1. Make SAMBA inherit
1. Modes and masks
2. DOS Attributes
1. Setting the Read Only attribute
2. Using the X-bit
3. Using extended attributes
3. NTACLs in SAMBA
4. Catch: Microsoft Office
5. References

Microsoft Windows has a different way of assigning rights. To get SAMBA to play nicely with both the GNU/Linux filesystem and the Windows system can sometimes be a problem. So let us have a look at how Windows assigns permissions to users and groups, this way we get a better understanding of what the problems are. The different permission settings in a Windows system are:

Modify

The modify permission is needed to rename or delete a file

Read & Execute

You are able to execute the script or program

Read

With the read permission you are able to read the contents of a file

Write

With the write permission, you can modify the contents of a file but you can't rename or delete it

Full Control

You can do everything

I expect the GNU/Linux system to be the basis of all access rights. All rights and ACLs should be changed through the use of GNU tools as described above. To accomplish this the first settings we are going to set in the smb.conf per share is the inherit permissions and inherit acls settings:

   inherit permissions    = yes
   inherit acls           = yes

With inheritance installed we do not need create mask, force create mode, directory mask and force directory mode, because that is overwritten by the inherit permissions setting, making our setup easier to read. Within SAMBA there are only a couple more entries that can be used to control the file permissions:

security mask

This is an AND function on the incoming bits. Meaning that when ever there is 0 in this mask the rights are taken away from the incoming bits.

force security mode

This is an OR function on the incoming bits. Meaning that when ever there is 1 in this mask the resulting out come is also a 1. When set to 0 all permissions can be changed by the user.

directory security mask

This is an AND function on the incoming bits. Meaning that when ever there is 0 in this mask the rights are taken away from the incoming bits.

force directory security mode

This is an OR function on the incoming bits. Meaning that when ever there is 1 in this mask the resulting out come is also a 1. When set to 0 all permissions can be changed by the user.

Normal documents and files do not have the eXecute bit set. SAMBA can use this X-bit to provide extra DOS file attributes, but one can also use the extended attributes to store the DOS attribute information.

The DOS file system has a READ ONLY bit. This means that if this bit is set, the file is regarded as read only. SAMBA can set this bit by using the map read only setting. The default for this setting is yes, which means that the POSIX user-write bit determines the state of READ ONLY bit. When the write bit is not set on the POSIX system, the READ ONLY bit is set in the DOS attributes. This is regardless of the owner being the user accessing the file.

Another option for this setting is: permissions. Then the state of the DOS READ ONLY attribute is set by the effective rights of the user trying to access the file.

If the option is set to no, then the state can only be set by the store dos attributes method, for all other use the read only bit is never set.

If store dos attributes is set to yes then these parameters work as a fall back, unless you set them all to no. See the "Using extended attributes" section for more on this option.

SAMBA can use the extended user attributes to store the DOS file attributes. It can even put the inherit and protected access control entry flags stored in Windows ACLs into an extended attribute. To use this functionality the disk that provides the SAMBA shares should be mounted with the user_xattr option.

store dos attributes

map acl inherit

As of SAMBA version 3.3 there is a back ported VFS module called vfs_acl_xatter, which enables the full mapping of Windows ACLs on SAMBA servers. The ACLs received from a Windows system is stored in an Extended Attribute called security.NTACL. Note that this attribute is not shown by the getfattr -d filename, it can only be retreived by naming it as in: getfattr -n security.NTACL filename.

To enbale this feature for a share add to the share definition in you smb.conf the line:

vfs objects = acl_xattr

Next to storing the Windows ACL information into an Extended Attribute (EA), SAMBA will try to map the access rights to the rights of the underlying file system, as of SAMBA 3.5.6 this works very well. How well this works depends on the file system at hand. If you manually change an ACL on the host system, that is also having a Windows ACL in an EA, SAMBA will remove the Windows ACL from the EA and regenerate the EA from the host systems view on the file access rights. So if the goal is to maintain the Windows ACLs one should not fiddle with the ACLs on the host system.

The fact that SAMBA tries to map the Windows ACL into an ACL on the hosts file system means that the host machine must also support ACLs. For ext3 and ext4 you can add the acl option when mounting the file system. However the default ACLs (more or less the abandoned draft POSIX.1e standard), do not map well to the ACLs of Windows. Better support is provided by the NFSv4 ACLs, which are more or less a copy of the Windows ACLs. To enable this feature on ext3 use the acl=nfs4 mount option. For ext4 use the richacl mount option.

There is currently no way to ONLY store the Windows ACLs and not adjust the hosts ACLs. From a mailinglist post of Jeremy Allison dated Dec 13, 2004:

You could slot in a "null" ACL module underneath the acl_xattr
layer that always allowed acl set and returned an "allow everyone"
acl on read, but that isn't coded yet (shouldn't be too hard
though).

Currently if you want "native" NT ACLs only I suggest you
use the NFSv4 module, which is pretty close to native Windows
ACLs.

When requesting the ACLs on a file or directory from SAMBA using smbcacls or using Windows through Properties->Security the NTACLs are shown. The Windows ACLs can deny additional access, but not override the ACLs of the host system. Note that both ACL systems are considered when accessing a file!

Our normal settings for a group directory are 2750, and the files within that directory have 0770. This works perfectly, except for Microsoft Office. Via some dumb testing by changing all the different settings we found that it only worked when we have the directory on 2770. The SAMBA HOWTO Collection had the answer: Word does the following when you modify/change a Word document: MS Word creates a new document with a temporary name. Word then closes the old document and deletes it, then renames the new document to the original document name.

So MS Office actually creates a new file, instead of rewritting the original file... I think this is another reason to use Open Office.

A bit dated document, but with a lot more information, can be found on the SAMBA site: Chapter 16