Section 6.3. Access Control Lists

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:

  • Additional named users

  • Additional named groups

  • A group mask

  • Default ACLs for directories

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:

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

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

  3. 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:

     inherit acls = yes 

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.

Table 6-9. ACL options






acl map full control


Should Samba report the Unix permission set rwx as Full Control to Windows clients?



inherit acls


If enabled, ensures that default ACLs on directories are propagated to new files and folders. The default behavior is to use the mode requested by the client.



nt acl support


Determines whether smbd reports support for ACLs when queried for information about the share.



map acl inherit


Should Samba remember an ACL's inherited properties and whether the ACL should be propagated to subfolders and files?



6.3.3. Understanding the Explorer Security Tab

Understanding how the security tab displayed on a Windows client relates to the underlying filesystem permissions is the final key to making effective use of Samba's ACL support. If the file memo.doc has the Unix permission shown here, Figure 6-4 displays how a Windows user would view the same access rights.

Figure 6-4. Displaying Unix permission for memo.doc using the Security dialog box

 $ ls -l memo.doc -rw-r----  1 lizard staff 32455 2006-05-25 09:40 memo.doc 

Adding named users and groups to the file access list does not change the permissions display model. The end user sees more account entries, but the mapping between a Unix permissions set and Windows access mask works the same.

The display model becomes slightly more complicated once we introduce folders. Consider the ACL for the archives directory given here:

 $ getfacl archives # file: archives # owner: lizard # group: staff user::rwx group::rwx group:helpdesk:r-x mask::rwx other::r-x default:user::rwx default:user:lizard:rwx default:group::--- default:group:staff:rwx default:group:helpdesk:r-x default:mask::rwx default:other::--- 

The basic permissions in this ACL are displayed by Windows as shown in Figure 6-5, and the advanced options are displayed as shown in Figure 6-6.

Figure 6-5. Displaying the Unix ACL for the archives folder using the Windows Security dialog box

Figure 6-6. Displaying the Unix ACL for the archives folder using the Advanced Security dialog box

Several complexities involved in viewing ACLs from Windows can render them confusing. A permission is displayed in the general security tab (Figure 6-5) only if the permission applies to "This folder, subfolder, and files" (Figure 6-6). Samba interprets the access entries (e.g., group:helpdesk:r-x) to apply to "This folder." The default access entries (e.g., default:group:helpdesk:r-x) apply to "Subfolders and files." Therefore, to display the permissions in the initial security dialog box, a user or group must have both an access entry and a default entry. Users and groups do not have to have default access entries in order to function properly, but it is important to understand why an account's permissions may not be displayed on the initial security tab view. The complete security permissions are always available by navigating to the Permissions tab of the Advanced Security dialog box shown in Figure 6-6.

Next is the question of the CREATOR OWNER and CREATOR GROUP entries. Samba maps these Windows accounts to the default owner and group ACEs. In order for the owner's permissions to apply to "This folder, subfolder, and files," she must also have a named default entry. Here's an abbreviated version of the original POSIX ACL that highlights the entries needed to list both a CREATOR OWNER entry and to display lizard's permissions in the initial security dialog box:

 # owner: lizard user::rwx default:user::rwx default:user:lizard:rwx 

Viewing ACLs from Windows is of minimal use if you are unable to modify them. Samba converts ACL modifications sent by the client to its own filesystem representation using the inverse of the display rules just discussed. There are a few differences between Windows and Unix that you must remember:

  • Unix allows only root or the owner to change the permissions on a file or directory.

  • Only root or a user possessing the SeTakeOwnership privilege can assume ownership of a file or directory.

  • Only root or a user possessing the SeRestorePrivilege privilege can set ownership to an arbitrary user.

If you wish to enforce semantics similar to those on Windows, where any user with write permissions can modify the ACL or take ownership, set dos filemode = yes in the share definition. This control option and a related one are summarized in Table 6-10.

Table 6-10. DOS compatibility options






dos filemode


Should users with write access be able to assume ownership and modify the object's ACL?



dos filetimes


Should users with write access be able to modify the file's timestamp?



Using Samba
Using Samba: A File and Print Server for Linux, Unix & Mac OS X, 3rd Edition
ISBN: 0596007698
EAN: 2147483647
Year: 2004
Pages: 135 © 2008-2017.
If you may any questions please contact us: