Section 5.5. Controlling Authorization for File Shares

5.5. Controlling Authorization for File Shares

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:

• Security descriptor

• Access controls in the share's definition in smb.conf

• 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 definedfor example, valid users = +staffeveryone 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

Parameter	Value	Description	Default	Scope
admin users	user/group list	List of users or members of a group who are mapped to the root user for all access to this share.	""	Share
invalid users	user/group list	List of users or members of a group who are denied access this share.	""	Share
max connections	integer	Defines the maximum number of concurrent connections to this share across all user sessions. A value of 0 indicates that access should not be restricted.	0	Share
read list	user/group list	List of users or members of a group who are restricted to read only access to this share.	""	Share
valid users	user/group list	List of users or members of a group who are granted access to this share, if permitted by the other authorization checks as well.	""	Share
write list	user/group list	List of users or members of a group who are granted write access to this share, if permitted by the other access checks on the share and filesystem permissions as well.	""	Share