Authorizing Users in Samba - Controlling Authorization for File Shares (Page 4 of 4 )
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 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
Parameter | Value | Description | Default | Scope |
admin users | user/group list | List of users or members of a group who are mapped to the rootuser 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 con-nections 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 autho-rization 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 permis-sions as well. | "" | Share |
* 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.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article is excerpted from chapter five of Using Samba, Third Edition, written by Gerald Carter, Jay Ts and Robert Eckstein (O'Reilly, 2007; ISBN: 0596007698). Check it out today at your favorite bookstore. Buy this book now.
|
|
