Controlling Authorization for File Shares - Administration

We began this chapter discussing authentication, and we now end it with a discussion about authorization. Authorization under Unix relies upon the user’s uid and a list of group gids. Samba can use this same information to perform preliminary access checks to to control whether the user or group should be allowed to modify any files within a share. For example, perhaps you would like to export a set of files as read-only to students but allow modification by teachers. There are several ways to accomplish this goal. The final access granted to a file or directory for a user is the most restrictive permission set allowed after passing the user credentials through the share’s:

1. Security descriptor
   
2. Access controls in the share’s definition in smb.conf
   
3. Filesystem permissions

The initial access check is performed by comparing against the share’s security descriptor. These share permissions are maintained separately from the server’s configuration file and are stored by default in /usr/local/samba/var/locks/share_info.tdb. All shares initially have a neutral ACL that grants Everyone full control of the share.

Figure 5-4 shows the share permissions for [public] viewed from the Computer Management MMC plug-in connected to a Samba host. Expand the Systems Tools -> Share Folders -> Share hierarchy to list the available file shares. Finally, select an individual share and right-click to navigate to the Properties menu option. The security tab in the dialog box that appears provides access to the share ACL settings. Note that you will not be able to modify the security descriptor unless you are connected as root or possess the SeDiskOperatorPrivilege .

Figure 5-4.  Share permissions for \\RAIN\public

Next, we focus on the category of smb.conf authorization options that make use of a list of names. Consider the admin users option as a first example. This option accepts a list of users or group members that should be mapped to the root account when they access resources on a given share. Assume that we want to allow the users rose and lily to be able to manipulate files regardless of the filesystem permissions. A basic way to achieve this is to add the admin users list to the share definition in smb.conf:

  [documents]
      path = /data/docs
      read only = no
      admin users = rose, lily

When a user connects, Samba determines whether that user is a contained within the list rose, lily. Evaluating user names is straightforward. A single string comparison returns success or failure depending on whether the login names match.

Authorization lists such as admin users can accept group names as well. The next example expands the [documents] share to add the Unix group named staff as a member of the admin users list:

  [documents]
      path = /data/docs
      read only = no
      admin users = rose, lily, +staff

When a name is prefixed by the plus sign ( + ), Samba resolves that name as a Unix group by querying the operating system for its membership. Once the list of user names is expanded, the login name comparison continues until a match is found or until all the members in the list have been checked.

Any files or directories created by a user contained in the admin users list will be owned by root, not the actual user.

In most cases, the + character is all that is needed. There are two other available characters to inform Samba of the properties of a name:

@   Attempt to resolve the name as an NIS netgroup,
      and fall back to evaluating it as a Unix group in 
      case of failure.

&   Attempt to resolve the name as an NIS netgroup, 
      with no fallback mechanism in the case of failure.

It is very likely that Samba’s support for NIS will be deprecated at some point, so don’t rely upon the @ and & characters unless you actually use netgroups. Doing so prevents you from having to update your smb.conf, should support for descriptive characters other than + be removed.

Other parameters that make use of the user and group list syntax are frequently found in pairs. For example, the valid users and invalid users options allow and restrict specific users or groups from accessing a specific share. Although these parameters are not mutually exclusive, the configuration is much easier to understand when only one is present. If one parameter is defined—for example, valid users=+staff —everyone who does not belong to that list is considered to be invalid and is not allowed access to that share. This is a simple method to either disallow everyone and specify a few exceptions ( valid users ), or to authorize all users and then reject a few particular ones ( invalid users ). If both parameters are defined, a user must not appear in the invalid users list, but must match the valid users list.

Similarly, the read list and write list options provide a means of deviating from the read only setting for a user or group. A share may be marked as read only with the exception of a few users or groups. The following [administration] share is read only for those who do not belong to the pcadmins Unix group:

  [administration]
      path = /data/administration
      read only = yes
      write list = +pcadmins

In a complementary fashion, a share named [documents] is defined here to be modifiable by all users except those in the guest group:

  [documents]
      path = /data/documents
      read only = no
      read list = +guest

Finally, a share can be restricted to a maximum number of simultaneous connections across all user sessions by specifying a nonzero max connections parameter. This approach provides a crude mechanism for metering network software installations. For instance, if you have only 10 licenses for an application, you can install it in a dedicated Samba file share and have the clients run the software from there. To help illustrate the use of the option, the following example configures a share named [cad] that allows only 10 connections at any given time:

  [cad]
      comment = CAD software for Engineering Department
      path = /data/applications/cad
      read only = yes
      max connections = 10

Note that this example restricts only the number of connections to the share. It does not track how many users are currently running an application. A user who has the share open in a Windows Explorer window is consuming one of the connections, even without accessing any files contained in the share.

Table 5-18 concludes this chapter with an overview of the authorization parameters discussed in this section. In the next chapter, we examine many more configuration options and advanced capabilities of Samba’s file serving functionality.

Table 5-18. File share authorization-related parameters

* The term security level refers to the capabilities of the SMB/CIFS protocol and the term security mode describes Samba’s various implementations of the SMB/CIFS security levels.

* Details of NTLM and other authentication protocols used by CIFS can be found at Chris Hertel’s site http://ubiqx.org/cifs.

* Samba 2.2 did support both the LDAP and TDB storage backends. But it was only with the Samba 3.0 releases that developers considered these to be first-class citizens when managing user accounts.

* This is the posixGroup from the original RFC2307 schema and not the auxiliary version defined in the RFC2307bis extensions.

* In any discussion of Unix utilities, it is admittedly hard to remember which password-related options and files are called “password” and which are called “passwd.”

a Future versions of Samba will enable this feature by default. Be sure to check the current smb.conf(5) manpage for your version.