Home arrow Site Administration arrow Page 4 - Authorizing Users in Samba

Controlling Authorization for File Shares - Administration

In this conclusion to a four-part series that covers authentication and authorization in Samba, you will learn about group mapping, user privilege management, and more. 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). Copyright © 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

  1. Authorizing Users in Samba
  2. User Privilege Management
  3. The net Tool
  4. Controlling Authorization for File Shares
By: O'Reilly Media
Rating: starstarstarstarstar / 5
February 28, 2008

print this article



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:

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:

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:

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:

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:

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






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.



invalid users

user/group list

List of users or members of a group who are denied access this share.



max connections


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.



read list

user/group list

List of users or members of a group who are restricted to read only access to this 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.



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.



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

>>> More Site Administration Articles          >>> More By O'Reilly Media

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: