Section 6.3. Access Control Lists
Windows filesystems’ ACLs, sometimes referred to generically as security descriptors , support a wide variety of permissions masks. The Windows access masks are in fact much richer than the standard read/write/execute permissions provide by Unix systems. Therefore, Samba 3.0 supports a lossy mapping between Unix filesystem permissions and Windows ACLs. For example, when a Windows file specifying that the user rose has Full Control is copied to a Samba server, the Full Control access mask is mapped onto the permissions set rwx. All of the other bits in the Windows access mask, representing things such as delete and take ownership permissions, are simply thrown away. To ensure this behavior is symmetric, when translating an ACL in the reverse direction, from Unix to Windows, the rwx permissions on the Unix host are reported as Full Control to the Windows client.
You can prevent smbd from reporting rwx as Full Control by disabling the map acl full control Boolean parameter in the share’s definition.
The belief among Samba developers is that by supporting Read, Write, and Full Control permissions, the majority of Samba and Windows users are satisfied. The remainder of this section is dedicated to how Windows access masks are converted to Unix permission sets and vice versa, which applies whether the Samba host supports ACLs or only the standard Unix permission model. Let’s begin our discussion with ACLs.
Samba supports various Unix filesystem ACL implementations. To enable Samba’s compile checks for ACL support, pass the --with-acl-support option to the configure script. Currently Samba can support only one ACL implementation at a time. For example, if filesystem type A had one ACL interface and filesystem type B utilized a different one, Samba could interact with the ACLs on only one of those filesystems at a time. So far, this limitation has not been an issue, because most filesystems on a given operating system support a common API.
More information about a server’s ACL implementation can often be found by running man acl.
You can determine whether your Samba installation has been built to include ACL support by examining the output from smbd -b. A Linux host should report HAVE_POSIX_ACLS, and another operating system such as Solaris should define HAVE_SOLARIS_ACLS. The following example shows that the Samba installation on our Linux server does in fact include ACL support:
$ smbd -b | grep HAVE.*ACL HAVE_POSIX_ACLS
If this check fails, make sure that the ACL libraries and development files are installed. On Linux hosts, these can generally be found in a package named libacl-devel. You should also verify that the server’s filesystem included the acl option when it was mounted:
$ mount /dev/hda2 on / type ext3 (rw,acl,user_xattr) .
If you experience any problems with the filesystem, please refer to your operating system’s documentation for possible remedies.
Before we discuss the configuration of support for Windows ACLs in smb.conf , we will briefly explain the POSIX ACL model. Figure 6-3 illustrates how Samba uses a POSIX ACL as the intermediate form between the Windows security descriptor and the real filesystem ACL representation.
Figure 6-3. Mapping from Windows security descriptors to Unix filesystem ACLs
6.3.1. What’s in a POSIX ACL?
The POSIX ACL standard was never finished. However, many operating systems, including Linux 2.6, implement the 1003.1e draft of the specification. A POSIX access control list is basically a Unix permission set plus four things:
Named users and groups are simply additional user and group permission sets. A POSIX ACL still has the concept of an owner (user::) and a group owner (group::). A named user or group is specified by a single character (a u for a user or a g for a group) followed by a colon and the account name, followed by another colon and the permission set. The following directory ( logs) as shown below has an owner names lizard , a group owner of webdev , and a named user of rose :
$ getfacl logs # file: logs # owner: lizard # group: webdev user::rwx group::rwx mask::rwx u:rose:r-- other::r-x
When evaluating the permissions granted to a particular user, the process is as follows:
- Search for a user: entry matching the account name. This step includes comparing against the owner of the object. If a match is found, use the associated permissions set.
- Create a permissions set by combining the access masks from all the listed groups to which the user belongs and perform a logical AND with the ACL group mask. Continue to the next check only if the user did not belong to any of the listed groups.
- Use the world permission set.
The final addition by POSIX ACLs are the default access control entries (ACE) that may be associated with directories. These default ACLs apply to any newly created files or folders contained by the directory. This feature is similar to Samba’s inherit permissions parameter. A default ACE follows the same rules as normal access entries. It may have user and group owner entries, named users and groups, a mask, and world permissions. Here is a short example of what the remainder of the logs directory ACL looks like:
default:user::rwx default:group::rwx default:u:rose:r-x default:mask::rwx default:other::r-x
We discuss default access control entries in more detail when we examine POSIX ACLs from the Windows Explorer security tab.
6.3.2. The nt acl support Parameter
Now that we have verified Samba compile support for Unix ACLs and have a solid understanding of POSIX ACLs, it is time to create an ACL-aware share in smb.conf. When creating a file share supporting either ACLs or the simpler Unix permission bit model, the nt acl support parameter must be enabled. Here is a share named [public] that we will use for discussion:
[public] path = /data/public read only = no nt acl support = yes
Windows 2000 and later Microsoft operating systems support a semidynamic model of ACL inheritance. The filesystem maintains a history of where an ACL assigned to a file or folder came from. For example, was it manually set for just this object? Or has it been inherited from its parent? The reason we refer to this as «semidynamic» is that when changing an ACE on a parent folder, the client host walks the directory tree and applies the new changes to any files or subdirectories that have inherited the setting. Samba is able to support this same semidynamic model by storing ACL inheritance information in an object’s extended attributes. Refer to the previous section on DOS attributes if you need to verify support for extended attributes on your server.
In order to enable Windows ACL inheritance, you must add the map acl inherit Boolean parameter to [public] :
[public] path = /data/public read only = no store dos attributes = yes nt acl support = yes map acl inherit = yes
Finally, to ensure that the default ACLs on directories are propagated correctly, add the inherit acls Boolean option:
It is still possible to use inherit permissions in combination with ACLs, but the option will be honored only if the parent directory has no default access entries.
Before we continue on to a discussion of how these permission sets and access lists are viewed by users, Table 6-9 summarizes the ACL parameters we have covered so far.