summaryrefslogtreecommitdiff
path: root/docs/htmldocs/AccessControls.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/AccessControls.html')
-rw-r--r--docs/htmldocs/AccessControls.html652
1 files changed, 652 insertions, 0 deletions
diff --git a/docs/htmldocs/AccessControls.html b/docs/htmldocs/AccessControls.html
new file mode 100644
index 0000000000..9a15b01948
--- /dev/null
+++ b/docs/htmldocs/AccessControls.html
@@ -0,0 +1,652 @@
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 13. File, Directory and Share Access Controls</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="groupmapping.html" title="Chapter 12. Group Mapping MS Windows and UNIX"><link rel="next" href="locking.html" title="Chapter 14. File and Record Locking"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 13. File, Directory and Share Access Controls</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="locking.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="AccessControls"></a>Chapter 13. File, Directory and Share Access Controls</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email">&lt;<a href="mailto:jht@samba.org">jht@samba.org</a>&gt;</tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email">&lt;<a href="mailto:jra@samba.org">jra@samba.org</a>&gt;</tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><span class="contrib">drawing</span><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><tt class="email">&lt;<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>&gt;</tt></p></div></div></div></div><div><p class="pubdate">May 10, 2003</p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="AccessControls.html#id2911341">Features and Benefits</a></dt><dt><a href="AccessControls.html#id2911525">File System Access Controls</a></dt><dd><dl><dt><a href="AccessControls.html#id2911543">MS Windows NTFS Comparison with UNIX File Systems</a></dt><dt><a href="AccessControls.html#id2911956">Managing Directories</a></dt><dt><a href="AccessControls.html#id2912050">File and Directory Access Control</a></dt></dl></dd><dt><a href="AccessControls.html#id2912290">Share Definition Access Controls</a></dt><dd><dl><dt><a href="AccessControls.html#id2912329">User and Group-Based Controls</a></dt><dt><a href="AccessControls.html#id2912779">File and Directory Permissions-Based Controls</a></dt><dt><a href="AccessControls.html#id2913187">Miscellaneous Controls</a></dt></dl></dd><dt><a href="AccessControls.html#id2913585">Access Controls on Shares</a></dt><dd><dl><dt><a href="AccessControls.html#id2913670">Share Permissions Management</a></dt></dl></dd><dt><a href="AccessControls.html#id2913978">MS Windows Access Control Lists and UNIX Interoperability</a></dt><dd><dl><dt><a href="AccessControls.html#id2913986">Managing UNIX Permissions Using NT Security Dialogs</a></dt><dt><a href="AccessControls.html#id2914042">Viewing File Security on a Samba Share</a></dt><dt><a href="AccessControls.html#id2914124">Viewing File Ownership</a></dt><dt><a href="AccessControls.html#id2914264">Viewing File or Directory Permissions</a></dt><dt><a href="AccessControls.html#id2914515">Modifying File or Directory Permissions</a></dt><dt><a href="AccessControls.html#id2914698">Interaction with the Standard Samba create mask Parameters</a></dt><dt><a href="AccessControls.html#id2915106">Interaction with the Standard Samba File Attribute Mapping</a></dt></dl></dd><dt><a href="AccessControls.html#id2915195">Common Errors</a></dt><dd><dl><dt><a href="AccessControls.html#id2915209">Users Cannot Write to a Public Share</a></dt><dt><a href="AccessControls.html#id2915635">File Operations Done as root with force user Set</a></dt><dt><a href="AccessControls.html#id2915690">MS Word with Samba Changes Owner of File</a></dt></dl></dd></dl></div><p>
+<a class="indexterm" name="id2911255"></a>
+Advanced MS Windows users are frequently perplexed when file, directory and share manipulation of
+resources shared via Samba do not behave in the manner they might expect. MS Windows network
+administrators are often confused regarding network access controls and how to
+provide users with the access they need while protecting resources from unauthorized access.
+</p><p>
+Many UNIX administrators are unfamiliar with the MS Windows environment and in particular
+have difficulty in visualizing what the MS Windows user wishes to achieve in attempts to set file
+and directory access permissions.
+</p><p>
+The problem lies in the differences in how file and directory permissions and controls work
+between the two environments. This difference is one that Samba cannot completely hide, even
+though it does try to bridge the chasm to a degree.
+</p><p>
+<a class="indexterm" name="id2911291"></a>
+<a class="indexterm" name="id2911300"></a>
+
+POSIX Access Control List technology has been available (along with Extended Attributes)
+for UNIX for many years, yet there is little evidence today of any significant use. This
+explains to some extent the slow adoption of ACLs into commercial Linux products. MS Windows
+administrators are astounded at this, given that ACLs were a foundational capability of the now
+decade-old MS Windows NT operating system.
+</p><p>
+The purpose of this chapter is to present each of the points of control that are possible with
+Samba-3 in the hope that this will help the network administrator to find the optimum method
+for delivering the best environment for MS Windows desktop users.
+</p><p>
+This is an opportune point to mention that Samba was created to provide a means of interoperability
+and interchange of data between differing operating environments. Samba has no intent to change
+UNIX/Linux into a platform like MS Windows. Instead the purpose was and is to provide a sufficient
+level of exchange of data between the two environments. What is available today extends well
+beyond early plans and expectations, yet the gap continues to shrink.
+</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2911341"></a>Features and Benefits</h2></div></div><div></div></div><p>
+ Samba offers a lot of flexibility in file system access management. These are the key access control
+ facilities present in Samba today:
+ </p><div class="itemizedlist"><p class="title"><b>Samba Access Control Facilities</b></p><ul type="disc"><li><p>
+ <a class="indexterm" name="id2911368"></a>
+ <span class="emphasis"><em>UNIX File and Directory Permissions</em></span>
+ </p><p>
+ Samba honors and implements UNIX file system access controls. Users
+ who access a Samba server will do so as a particular MS Windows user.
+ This information is passed to the Samba server as part of the logon or
+ connection setup process. Samba uses this user identity to validate
+ whether or not the user should be given access to file system resources
+ (files and directories). This chapter provides an overview for those
+ to whom the UNIX permissions and controls are a little strange or unknown.
+ </p></li><li><p>
+ <span class="emphasis"><em>Samba Share Definitions</em></span>
+ </p><p>
+ In configuring share settings and controls in the <tt class="filename">smb.conf</tt> file,
+ the network administrator can exercise overrides to native file
+ system permissions and behaviors. This can be handy and convenient
+ to effect behavior that is more like what MS Windows NT users expect
+ but it is seldom the <span class="emphasis"><em>best</em></span> way to achieve this.
+ The basic options and techniques are described herein.
+ </p></li><li><p>
+ <span class="emphasis"><em>Samba Share ACLs</em></span>
+ <a class="indexterm" name="id2911453"></a>
+ </p><p>
+ Just like it is possible in MS Windows NT to set ACLs on shares
+ themselves, so it is possible to do this in Samba.
+ Few people make use of this facility, yet it remains on of the
+ easiest ways to affect access controls (restrictions) and can often
+ do so with minimum invasiveness compared with other methods.
+ </p></li><li><p>
+ <a class="indexterm" name="id2911481"></a>
+ <a class="indexterm" name="id2911492"></a>
+ <span class="emphasis"><em>MS Windows ACLs through UNIX POSIX ACLs</em></span>
+ </p><p>
+ The use of POSIX ACLs on UNIX/Linux is possible only if the underlying
+ operating system supports them. If not, then this option will not be
+ available to you. Current UNIX technology platforms have native support
+ for POSIX ACLs. There are patches for the Linux kernel that also provide
+ this. Sadly, few Linux platforms ship today with native ACLs and
+ Extended Attributes enabled. This chapter has pertinent information
+ for users of platforms that support them.
+ </p></li></ul></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2911525"></a>File System Access Controls</h2></div></div><div></div></div><p>
+Perhaps the most important recognition to be made is the simple fact that MS Windows NT4/200x/XP
+implement a totally divergent file system technology from what is provided in the UNIX operating system
+environment. First we consider what the most significant differences are, then we look
+at how Samba helps to bridge the differences.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2911543"></a>MS Windows NTFS Comparison with UNIX File Systems</h3></div></div><div></div></div><p>
+<a class="indexterm" name="id2911555"></a>
+<a class="indexterm" name="id2911563"></a>
+<a class="indexterm" name="id2911571"></a>
+<a class="indexterm" name="id2911582"></a>
+
+ Samba operates on top of the UNIX file system. This means it is subject to UNIX file system conventions
+ and permissions. It also means that if the MS Windows networking environment requires file system
+ behavior that differs from UNIX file system behavior then somehow Samba is responsible for emulating
+ that in a transparent and consistent manner.
+ </p><p>
+ It is good news that Samba does this to a large extent and on top of that provides a high degree
+ of optional configuration to override the default behavior. We look at some of these over-rides,
+ but for the greater part we will stay within the bounds of default behavior. Those wishing to explore
+ the depths of control ability should review the <tt class="filename">smb.conf</tt> man page.
+ </p><p>The following compares file system features for UNIX with those of Microsoft Windows NT/200x:
+ <a class="indexterm" name="id2911624"></a>
+
+ </p><div class="variablelist"><dl><dt><span class="term">Name Space</span></dt><dd><p>
+ MS Windows NT4/200x/XP files names may be up to 254 characters long, and UNIX file names
+ may be 1023 characters long. In MS Windows, file extensions indicate particular file types,
+ in UNIX this is not so rigorously observed as all names are considered arbitrary.
+ </p><p>
+ What MS Windows calls a folder, UNIX calls a directory.
+ </p></dd><dt><span class="term">Case Sensitivity</span></dt><dd><p>
+ <a class="indexterm" name="id2911680"></a>
+ <a class="indexterm" name="id2911689"></a>
+ MS Windows file names are generally upper case if made up of 8.3 (8 character file name
+ and 3 character extension. File names that are longer than 8.3 are case preserving and case
+ insensitive.
+ </p><p>
+ UNIX file and directory names are case sensitive and case preserving. Samba implements the
+ MS Windows file name behavior, but it does so as a user application. The UNIX file system
+ provides no mechanism to perform case insensitive file name lookups. MS Windows does this
+ by default. This means that Samba has to carry the processing overhead to provide features
+ that are not native to the UNIX operating system environment.
+ </p><p>
+ Consider the following. All are unique UNIX names but one single MS Windows file name:
+ </p><pre class="screen">
+ MYFILE.TXT
+ MyFile.txt
+ myfile.txt
+ </pre><p>
+ So clearly, in an MS Windows file name space these three files cannot co-exist, but in UNIX
+ they can.
+ </p><p>
+ So what should Samba do if all three are present? That which is lexically first will be
+ accessible to MS Windows users, the others are invisible and unaccessible any
+ other solution would be suicidal.
+ </p></dd><dt><span class="term">Directory Separators</span></dt><dd><p>
+ <a class="indexterm" name="id2911762"></a>
+ MS Windows and DOS uses the backslash <tt class="constant">\</tt> as a directory delimiter, and UNIX uses
+ the forward-slash <tt class="constant">/</tt> as its directory delimiter. This is handled transparently by Samba.
+ </p></dd><dt><span class="term">Drive Identification</span></dt><dd><p>
+ <a class="indexterm" name="id2911799"></a>
+ MS Windows products support a notion of drive letters, like <b class="command">C:</b> to represent
+ disk partitions. UNIX has no concept of separate identifiers for file partitions, each
+ such file system is mounted to become part of the overall directory tree.
+ The UNIX directory tree begins at <tt class="constant">/</tt> just like the root of a DOS drive is specified as
+ <tt class="constant">C:\</tt>.
+ </p></dd><dt><span class="term">File Naming Conventions</span></dt><dd><p>
+ <a class="indexterm" name="id2911846"></a>
+ MS Windows generally never experiences file names that begin with a dot (<tt class="constant">.</tt>) while in UNIX these
+ are commonly found in a user's home directory. Files that begin with a dot (<tt class="constant">.</tt>) are typically
+ either start-up files for various UNIX applications, or they may be files that contain
+ start-up configuration data.
+ </p></dd><dt><span class="term">Links and Short-Cuts</span></dt><dd><p>
+ <a class="indexterm" name="id2911886"></a>
+ <a class="indexterm" name="id2911897"></a>
+ <a class="indexterm" name="id2911908"></a>
+ MS Windows make use of &#8220;<span class="quote">links and short-cuts</span>&#8221; that are actually special types of files that will
+ redirect an attempt to execute the file to the real location of the file. UNIX knows of file and directory
+ links, but they are entirely different from what MS Windows users are used to.
+ </p><p>
+ Symbolic links are files in UNIX that contain the actual location of the data (file or directory). An
+ operation (like read or write) will operate directly on the file referenced. Symbolic links are also
+ referred to as &#8220;<span class="quote">soft links.</span>&#8221; A hard link is something that MS Windows is not familiar with. It allows
+ one physical file to be known simultaneously by more than one file name.
+ </p></dd></dl></div><p>
+ There are many other subtle differences that may cause the MS Windows administrator some temporary discomfort
+ in the process of becoming familiar with UNIX/Linux. These are best left for a text that is dedicated to the
+ purpose of UNIX/Linux training and education.
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2911956"></a>Managing Directories</h3></div></div><div></div></div><p>
+ There are three basic operations for managing directories: <b class="command">create, delete, rename</b>.
+ </p><div class="table"><a name="id2911975"></a><p class="title"><b>Table 13.1. Managing Directories with UNIX and Windows</b></p><table summary="Managing Directories with UNIX and Windows" border="1"><colgroup><col><col><col></colgroup><thead><tr><th align="center">Action</th><th align="center">MS Windows Command</th><th align="center">UNIX Command</th></tr></thead><tbody><tr><td align="center">create</td><td align="center">md folder</td><td align="center">mkdir folder</td></tr><tr><td align="center">delete</td><td align="center">rd folder</td><td align="center">rmdir folder</td></tr><tr><td align="center">rename</td><td align="center">rename oldname newname</td><td align="center">mv oldname newname</td></tr></tbody></table></div><p>
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2912050"></a>File and Directory Access Control</h3></div></div><div></div></div><p>
+ <a class="indexterm" name="id2912062"></a>
+ The network administrator is strongly advised to read foundational training manuals and reference materials
+ regarding file and directory permissions maintenance. Much can be achieved with the basic UNIX permissions
+ without having to resort to more complex facilities like POSIX Access Control Lists (ACLs) or Extended
+ Attributes (EAs).
+ </p><p>
+ UNIX/Linux file and directory access permissions involves setting three primary sets of data and one control set.
+ A UNIX file listing looks as follows:
+</p><pre class="screen">
+<tt class="prompt">$ </tt><b class="userinput"><tt>ls -la</tt></b>
+total 632
+drwxr-xr-x 13 maryo gnomes 816 2003-05-12 22:56 .
+drwxrwxr-x 37 maryo gnomes 3800 2003-05-12 22:29 ..
+dr-xr-xr-x 2 maryo gnomes 48 2003-05-12 22:29 muchado02
+drwxrwxrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado03
+drw-rw-rw- 2 maryo gnomes 48 2003-05-12 22:29 muchado04
+d-w--w--w- 2 maryo gnomes 48 2003-05-12 22:29 muchado05
+dr--r--r-- 2 maryo gnomes 48 2003-05-12 22:29 muchado06
+drwsrwsrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado08
+---------- 1 maryo gnomes 1242 2003-05-12 22:31 mydata00.lst
+--w--w--w- 1 maryo gnomes 7754 2003-05-12 22:33 mydata02.lst
+-r--r--r-- 1 maryo gnomes 21017 2003-05-12 22:32 mydata04.lst
+-rw-rw-rw- 1 maryo gnomes 41105 2003-05-12 22:32 mydata06.lst
+<tt class="prompt">$ </tt>
+</pre><p>
+ </p><p>
+ The columns above represent (from left to right): permissions, number of hard links to file, owner, group, size (bytes), access date, access time, file name.
+ </p><p>
+ An overview of the permissions field can be found in <link linkend="access1">.
+ </p><div class="figure"><a name="access1"></a><p class="title"><b>Figure 13.1. Overview of UNIX permissions field.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/access1.png" width="270" alt="Overview of UNIX permissions field."></div></div><p>
+ Any bit flag may be unset. An unset bit flag is the equivalent of &#8220;<span class="quote">cannot</span>&#8221; and is represented as a &#8220;<span class="quote">-</span>&#8221; character.
+
+ </p><div class="example"><a name="id2912202"></a><p class="title"><b>Example 13.1. Example File</b></p><pre class="programlisting">
+ -rwxr-x--- Means: The owner (user) can read, write, execute
+ the group can read and execute
+ everyone else cannot do anything with it.
+ </pre></div><p>
+
+ </p><p>
+ Additional possibilities in the [type] field are: c = character device, b = block device, p = pipe device, s = UNIX Domain Socket.
+ </p><p>
+ The letters <tt class="constant">rwxXst</tt> set permissions for the user, group and others as: read (r), write (w), execute (or access for directories) (x),
+ execute only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s),
+ sticky (t).
+ </p><p>
+ When the sticky bit is set on a directory, files in that directory may be unlinked (deleted) or renamed only by root or their owner.
+ Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on
+ directories, such as <tt class="filename">/tmp</tt>, that are world-writable.
+ </p><p>
+ When the set user or group ID bit (s) is set on a directory, then all files created within it will be owned by the user and/or
+ group whose `set user or group' bit is set. This can be helpful in setting up directories for which it is desired that
+ all users who are in a group should be able to write to and read from a file, particularly when it is undesirable for that file
+ to be exclusively owned by a user whose primary group is not the group that all such users belong to.
+ </p><p>
+ When a directory is set <tt class="constant">drw-r-----</tt> this means that the owner can read and create (write) files in it, but because
+ the (x) execute flags are not set, files cannot be listed (seen) in the directory by anyone. The group can read files in the
+ directory but cannot create new files. If files in the directory are set to be readable and writable for the group, then
+ group members will be able to write to (or delete) them.
+ </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2912290"></a>Share Definition Access Controls</h2></div></div><div></div></div><p>
+<a class="indexterm" name="id2912301"></a>
+The following parameters in the <tt class="filename">smb.conf</tt> file sections define a share control or effect access controls.
+Before using any of the following options, please refer to the man page for <tt class="filename">smb.conf</tt>.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2912329"></a>User and Group-Based Controls</h3></div></div><div></div></div><p>
+ User and group-based controls can prove quite useful. In some situations it is distinctly desirable to affect all
+ file system operations as if a single user were doing so. The use of the <a class="indexterm" name="id2912343"></a><i class="parameter"><tt>force user</tt></i> and
+ <a class="indexterm" name="id2912356"></a><i class="parameter"><tt>force group</tt></i> behavior will achieve this. In other situations it may be necessary to effect a
+ paranoia level of control to ensure that only particular authorized persons will be able to access a share or
+ its contents. Here the use of the <a class="indexterm" name="id2912374"></a><i class="parameter"><tt>valid users</tt></i> or the
+ <a class="indexterm" name="id2912388"></a><i class="parameter"><tt>invalid users</tt></i> may be most useful.
+ </p><p>
+ As always, it is highly advisable to use the least difficult to maintain and the least ambiguous method for
+ controlling access. Remember, when you leave the scene someone else will need to provide assistance and
+ if he finds too great a mess or does not understand what you have done, there is risk of
+ Samba being removed and an alternative solution being adopted.
+ </p><p>
+ <link linkend="ugbc"> enumerates these controls.
+ </p><div class="table"><a name="ugbc"></a><p class="title"><b>Table 13.2. User and Group Based Controls</b></p><table summary="User and Group Based Controls" border="1"><colgroup><col align="left"><col align="justify"></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td align="left"><a class="indexterm" name="id2912501"></a><i class="parameter"><tt>admin users</tt></i></td><td align="justify"><p>
+ List of users who will be granted administrative privileges on the share.
+ They will do all file operations as the super-user (root).
+ Any user in this list will be able to do anything they like on the share,
+ irrespective of file permissions.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912530"></a><i class="parameter"><tt>force group</tt></i></td><td align="justify"><p>
+ Specifies a UNIX group name that will be assigned as the default primary group
+ for all users connecting to this service.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912558"></a><i class="parameter"><tt>force user</tt></i></td><td align="justify"><p>
+ Specifies a UNIX user name that will be assigned as the default user for all users connecting to this service.
+ This is useful for sharing files. Incorrect use can cause security problems.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912586"></a><i class="parameter"><tt>guest ok</tt></i></td><td align="justify"><p>
+ If this parameter is set for a service, then no password is required to connect to the service. Privileges will be
+ those of the guest account.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912614"></a><i class="parameter"><tt>invalid users</tt></i></td><td align="justify"><p>
+ List of users that should not be allowed to login to this service.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912640"></a><i class="parameter"><tt>only user</tt></i></td><td align="justify"><p>
+ Controls whether connections with usernames not in the user list will be allowed.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912666"></a><i class="parameter"><tt>read list</tt></i></td><td align="justify"><p>
+ List of users that are given read-only access to a service. Users in this list
+ will not be given write access, no matter what the read only option is set to.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912694"></a><i class="parameter"><tt>username</tt></i></td><td align="justify"><p>
+ Refer to the <tt class="filename">smb.conf</tt> man page for more information -- this is a complex and potentially misused parameter.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912727"></a><i class="parameter"><tt>valid users</tt></i></td><td align="justify"><p>
+ List of users that should be allowed to login to this service.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912754"></a><i class="parameter"><tt>write list</tt></i></td><td align="justify"><p>
+ List of users that are given read-write access to a service.
+ </p></td></tr></tbody></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2912779"></a>File and Directory Permissions-Based Controls</h3></div></div><div></div></div><p>
+ The following file and directory permission-based controls, if misused, can result in considerable difficulty to
+ diagnose causes of misconfiguration. Use them sparingly and carefully. By gradually introducing each one by one,
+ undesirable side effects may be detected. In the event of a problem, always comment all of them out and then gradually
+ reintroduce them in a controlled way.
+ </p><p>
+ Refer to <link linkend="fdpbc"> for information regarding the parameters that may be used to affect file and
+ directory permission-based access controls.
+ </p><div class="table"><a name="fdpbc"></a><p class="title"><b>Table 13.3. File and Directory Permission Based Controls</b></p><table summary="File and Directory Permission Based Controls" border="1"><colgroup><col align="left"><col align="justify"></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td align="left"><a class="indexterm" name="id2912884"></a><i class="parameter"><tt>create mask</tt></i></td><td align="justify"><p>
+ Refer to the <tt class="filename">smb.conf</tt> man page.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912916"></a><i class="parameter"><tt>directory mask</tt></i></td><td align="justify"><p>
+ The octal modes used when converting DOS modes to UNIX modes when creating UNIX directories.
+ See also: directory security mask.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912942"></a><i class="parameter"><tt>dos filemode</tt></i></td><td align="justify"><p>
+ Enabling this parameter allows a user who has write access to the file to modify the permissions on it.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912969"></a><i class="parameter"><tt>force create mode</tt></i></td><td align="justify"><p>
+ This parameter specifies a set of UNIX mode bit permissions that will always be set on a file created by Samba.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2912996"></a><i class="parameter"><tt>force directory mode</tt></i></td><td align="justify"><p>
+ This parameter specifies a set of UNIX mode bit permissions that will always be set on a directory created by Samba.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2913024"></a><i class="parameter"><tt>force directory security mode</tt></i></td><td align="justify"><p>
+ Controls UNIX permission bits modified when a Windows NT client is manipulating UNIX permissions on a directory.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2913052"></a><i class="parameter"><tt>force security mode</tt></i></td><td align="justify"><p>
+ Controls UNIX permission bits modified when a Windows NT client manipulates UNIX permissions.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2913079"></a><i class="parameter"><tt>hide unreadable</tt></i></td><td align="justify"><p>
+ Prevents clients from seeing the existence of files that cannot be read.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2913105"></a><i class="parameter"><tt>hide unwriteable files</tt></i></td><td align="justify"><p>
+ Prevents clients from seeing the existence of files that cannot be written to. Unwriteable directories are shown as usual.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2913133"></a><i class="parameter"><tt>nt acl support</tt></i></td><td align="justify"><p>
+ This parameter controls whether smbd will attempt to map UNIX permissions into Windows NT access control lists.
+ </p></td></tr><tr><td align="left"><a class="indexterm" name="id2913160"></a><i class="parameter"><tt>security mask</tt></i></td><td align="justify"><p>
+ Controls UNIX permission bits modified when a Windows NT client is manipulating the UNIX permissions on a file.
+ </p></td></tr></tbody></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2913187"></a>Miscellaneous Controls</h3></div></div><div></div></div><p>
+ The following are documented because of the prevalence of administrators creating inadvertent barriers to file
+ access by not understanding the full implications of <tt class="filename">smb.conf</tt> file settings. See <link linkend="mcoc">.
+ </p><div class="table"><a name="mcoc"></a><p class="title"><b>Table 13.4. Other Controls</b></p><table summary="Other Controls" border="1"><colgroup><col align="justify"><col align="justify"></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td align="justify"><a class="indexterm" name="id2913282"></a><i class="parameter"><tt>case sensitive</tt></i>, <a class="indexterm" name="id2913296"></a><i class="parameter"><tt>default case</tt></i>, <a class="indexterm" name="id2913310"></a><i class="parameter"><tt>short preserve case</tt></i></td><td align="justify"><p>
+ This means that all file name lookup will be done in a case sensitive manner.
+ Files will be created with the precise file name Samba received from the MS Windows client.
+ </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2913339"></a><i class="parameter"><tt>csc policy</tt></i></td><td align="justify"><p>
+ Client Side Caching Policy - parallels MS Windows client side file caching capabilities.
+ </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2913365"></a><i class="parameter"><tt>dont descend</tt></i></td><td align="justify"><p>
+ Allows specifying a comma-delimited list of directories that the server should always show as empty.
+ </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2913392"></a><i class="parameter"><tt>dos filetime resolution</tt></i></td><td align="justify"><p>
+ This option is mainly used as a compatibility option for Visual C++ when used against Samba shares.
+ </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2913419"></a><i class="parameter"><tt>dos filetimes</tt></i></td><td align="justify"><p>
+ DOS and Windows allow users to change file time stamps if they can write to the file. POSIX semantics prevent this.
+ This option allows DOS and Windows behavior.
+ </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2913448"></a><i class="parameter"><tt>fake oplocks</tt></i></td><td align="justify"><p>
+ Oplocks are the way that SMB clients get permission from a server to locally cache file operations. If a server grants an
+ oplock, the client is free to assume that it is the only one accessing the file and it will aggressively cache file data.
+ </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2913477"></a><i class="parameter"><tt>hide dot files</tt></i>, <a class="indexterm" name="id2913492"></a><i class="parameter"><tt>hide files</tt></i>, <a class="indexterm" name="id2913505"></a><i class="parameter"><tt>veto files</tt></i></td><td align="justify"><p>
+ Note: MS Windows Explorer allows over-ride of files marked as hidden so they will still be visible.
+ </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2913532"></a><i class="parameter"><tt>read only</tt></i></td><td align="justify"><p>
+ If this parameter is yes, then users of a service may not create or modify files in the service's directory.
+ </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2913559"></a><i class="parameter"><tt>veto files</tt></i></td><td align="justify"><p>
+ List of files and directories that are neither visible nor accessible.
+ </p></td></tr></tbody></table></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2913585"></a>Access Controls on Shares</h2></div></div><div></div></div><p>
+<a class="indexterm" name="id2913597"></a>
+ This section deals with how to configure Samba per share access control restrictions.
+ By default, Samba sets no restrictions on the share itself. Restrictions on the share itself
+ can be set on MS Windows NT4/200x/XP shares. This can be an effective way to limit who can
+ connect to a share. In the absence of specific restrictions the default setting is to allow
+ the global user <tt class="constant">Everyone - Full Control</tt> (full control, change and read).
+ </p><p>
+ At this time Samba does not provide a tool for configuring access control setting on the share
+ itself. Samba does have the capacity to store and act on access control settings, but the only
+ way to create those settings is to use either the NT4 Server Manager or the Windows 200x MMC for
+ Computer Management.
+ </p><p>
+ Samba stores the per share access control settings in a file called <tt class="filename">share_info.tdb</tt>.
+ The location of this file on your system will depend on how Samba was compiled. The default location
+ for Samba's tdb files is under <tt class="filename">/usr/local/samba/var</tt>. If the <tt class="filename">tdbdump</tt>
+ utility has been compiled and installed on your system, then you can examine the contents of this file
+ by executing: <b class="command">tdbdump share_info.tdb</b> in the directory containing the tdb files.
+ </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2913670"></a>Share Permissions Management</h3></div></div><div></div></div><p>
+ The best tool for the task is platform dependant. Choose the best tool for your environment.
+ </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2913682"></a>Windows NT4 Workstation/Server</h4></div></div><div></div></div><p>
+ The tool you need to use to manage share permissions on a Samba server is the NT Server Manager.
+ Server Manager is shipped with Windows NT4 Server products but not with Windows NT4 Workstation.
+ You can obtain the NT Server Manager for MS Windows NT4 Workstation from Microsoft see details below.
+ </p><div class="procedure"><p class="title"><b>Procedure 13.1. Instructions</b></p><ol type="1"><li><p>
+ Launch the <span class="application">NT4 Server Manager</span>, click on the Samba server you want to administer. From the menu
+ select <span class="guimenu">Computer</span>, then click on <span class="guimenuitem">Shared Directories</span>.
+ </p></li><li><p>
+ Click on the share that you wish to manage, then click the <span class="guilabel">Properties</span> tab. then click
+ the <span class="guilabel">Permissions</span> tab. Now you can add or change access control settings as you wish.
+ </p></li></ol></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2913771"></a>Windows 200x/XP</h4></div></div><div></div></div><p>
+ On <span class="application">MS Windows NT4/200x/XP</span> system access control lists on the share itself are set using native
+ tools, usually from File Manager. For example, in Windows 200x, right click on the shared folder,
+ then select <span class="guimenuitem">Sharing</span>, then click on <span class="guilabel">Permissions</span>. The default
+ Windows NT4/200x permission allows &#8220;<span class="quote">Everyone</span>&#8221; full control on the share.
+ </p><p>
+ MS Windows 200x and later versions come with a tool called the <span class="application">Computer Management</span> snap-in for the
+ Microsoft Management Console (MMC). This tool is located by clicking on <span class="guimenu">Control Panel -&gt;
+ Administrative Tools -&gt; Computer Management</span>.
+ </p><div class="procedure"><p class="title"><b>Procedure 13.2. Instructions</b></p><ol type="1"><li><p>
+ After launching the MMC with the Computer Management snap-in, click the menu item <span class="guimenuitem">Action</span>,
+ and select <span class="guilabel">Connect to another computer</span>. If you are not logged onto a domain you will be prompted
+ to enter a domain login user identifier and a password. This will authenticate you to the domain.
+ If you are already logged in with administrative privilege, this step is not offered.
+ </p></li><li><p>
+ If the Samba server is not shown in the <span class="guilabel">Select Computer</span> box, type in the name of the target
+ Samba server in the field <span class="guilabel">Name:</span>. Now click the on <span class="guibutton">[+]</span> next to
+ <span class="guilabel">System Tools</span>, then on the <span class="guibutton">[+]</span> next to <span class="guilabel">Shared Folders</span> in the
+ left panel.
+ </p></li><li><p>
+ In the right panel, double-click on the share on which you wish to set access control permissions.
+ Then click the tab <span class="guilabel">Share Permissions</span>. It is now possible to add access control entities
+ to the shared folder. Remember to set what type of access (full control, change, read) you
+ wish to assign for each entry.
+ </p></li></ol></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
+ Be careful. If you take away all permissions from the <tt class="constant">Everyone</tt> user without removing this user,
+ effectively no user will be able to access the share. This is a result of what is known as
+ ACL precedence. Everyone with <span class="emphasis"><em>no access</em></span> means that <tt class="constant">MaryK</tt> who is part of the group
+ <tt class="constant">Everyone</tt> will have no access even if she is given explicit full control access.
+ </p></div></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2913978"></a>MS Windows Access Control Lists and UNIX Interoperability</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2913986"></a>Managing UNIX Permissions Using NT Security Dialogs</h3></div></div><div></div></div><p>
+<a class="indexterm" name="id2913998"></a>
+ Windows NT clients can use their native security settings dialog box to view and modify the
+ underlying UNIX permissions.
+ </p><p>
+ This ability is careful not to compromise the security of the UNIX host on which Samba is running, and
+ still obeys all the file permission rules that a Samba administrator can set.
+ </p><p>
+ Samba does not attempt to go beyond POSIX ACLs, so the various finer-grained access control
+ options provided in Windows are actually ignored.
+ </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ All access to UNIX/Linux system files via Samba is controlled by the operating system file access controls.
+ When trying to figure out file access problems, it is vitally important to find the identity of the Windows
+ user as it is presented by Samba at the point of file access. This can best be determined from the
+ Samba log files.
+ </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2914042"></a>Viewing File Security on a Samba Share</h3></div></div><div></div></div><p>
+ From an NT4/2000/XP client, right click on any file or directory in a Samba-mounted drive letter
+ or UNC path. When the menu pops up, click on the <span class="guilabel">Properties</span> entry at the bottom
+ of the menu. This brings up the file <tt class="constant">Properties</tt> dialog box. Click on the
+ <span class="guilabel">Security</span> tab and you will see three buttons: <span class="guibutton">Permissions</span>,
+ <span class="guibutton">Auditing</span>, and <span class="guibutton">Ownership</span>. The <span class="guibutton">Auditing</span>
+ button will cause either an error message <span class="errorname">`A requested privilege is not held by the client'</span>
+ to appear if the user is not the NT Administrator, or a dialog which is intended to allow an Administrator
+ to add auditing requirements to a file if the user is logged on as the NT Administrator. This dialog is
+ non-functional with a Samba share at this time, as the only useful button, the <span class="guibutton">Add</span>
+ button, will not currently allow a list of users to be seen.
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2914124"></a>Viewing File Ownership</h3></div></div><div></div></div><p>
+ Clicking on the <span class="guibutton">Ownership</span> button brings up a dialog box telling you who owns
+ the given file. The owner name will be displayed like this:
+ </p><p>
+ <b class="command">&#8220;<span class="quote">SERVER\user (Long name)</span>&#8221;</b>
+ </p><p>
+ <i class="replaceable"><tt>SERVER</tt></i> is the NetBIOS name of the Samba server, <i class="replaceable"><tt>user</tt></i>
+ is the user name of the UNIX user who owns the file, and <i class="replaceable"><tt>(Long name)</tt></i> is the
+ descriptive string identifying the user (normally found in the GECOS field of the UNIX password database).
+ Click on the <span class="guibutton">Close </span> button to remove this dialog.
+ </p><p>
+ If the parameter <a class="indexterm" name="id2914189"></a><i class="parameter"><tt>nt acl support</tt></i> is set to <tt class="constant">false</tt>,
+ the file owner will be shown as the NT user <span class="emphasis"><em>Everyone</em></span>.
+ </p><p>
+ The <span class="guibutton">Take Ownership</span> button will not allow you to change the ownership of this file to
+ yourself (clicking it will display a dialog box complaining that the user you are currently logged onto
+ the NT client cannot be found). The reason for this is that changing the ownership of a file is a privileged
+ operation in UNIX, available only to the <span class="emphasis"><em>root</em></span> user. As clicking on this button causes
+ NT to attempt to change the ownership of a file to the current user logged into the NT clienti, this will
+ not work with Samba at this time.</p><p>
+ There is an NT <b class="command">chown</b> command that will work with Samba and allow a user with Administrator privilege connected
+ to a Samba server as root to change the ownership of files on both a local NTFS filesystem or remote mounted NTFS
+ or Samba drive. This is available as part of the <span class="application">Seclib</span> NT security library written
+ by Jeremy Allison of the Samba Team, and is available from the main Samba FTP site.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2914264"></a>Viewing File or Directory Permissions</h3></div></div><div></div></div><p>
+ The third button is the <span class="guibutton">Permissions</span> button. Clicking on this brings up a dialog box
+ that shows both the permissions and the UNIX owner of the file or directory. The owner is displayed like this:
+ </p><p><b class="command"><i class="replaceable"><tt>SERVER</tt></i>\
+ <i class="replaceable"><tt>user</tt></i>
+ <i class="replaceable"><tt>(Long name)</tt></i></b></p><p>Where <i class="replaceable"><tt>SERVER</tt></i> is the NetBIOS name of the Samba server,
+ <i class="replaceable"><tt>user</tt></i> is the user name of the UNIX user who owns the file, and
+ <i class="replaceable"><tt>(Long name)</tt></i> is the descriptive string identifying the user (normally found in the
+ GECOS field of the UNIX password database).</p><p>
+ If the parameter <a class="indexterm" name="id2914328"></a><i class="parameter"><tt>nt acl support</tt></i> is set to <tt class="constant">false</tt>,
+ the file owner will be shown as the NT user <tt class="constant">Everyone</tt> and the permissions will be
+ shown as NT &#8220;<span class="quote">Full Control</span>&#8221;.
+ </p><p>
+ The permissions field is displayed differently for files and directories, so I'll describe the way file permissions
+ are displayed first.
+ </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2914362"></a>File Permissions</h4></div></div><div></div></div><p>The standard UNIX user/group/world triplet and the corresponding <tt class="constant">read, write, execute</tt> permissions
+ triplets are mapped by Samba into a three element NT ACL with the &#8220;<span class="quote">r</span>&#8221;, &#8220;<span class="quote">w</span>&#8221; and &#8220;<span class="quote">x</span>&#8221; bits mapped into the corresponding
+ NT permissions. The UNIX world permissions are mapped into the global NT group <tt class="constant">Everyone</tt>, followed
+ by the list of permissions allowed for UNIX world. The UNIX owner and group permissions are displayed as an NT
+ <span class="guiicon">user</span> icon and an NT <span class="guiicon">local group</span> icon, respectively, followed by the list
+ of permissions allowed for the UNIX user and group.</p><p>Because many UNIX permission sets do not map into common NT names such as <tt class="constant">read</tt>,
+ <tt class="constant">change</tt> or <tt class="constant">full control</tt>, usually the permissions will be prefixed
+ by the words <tt class="constant">Special Access</tt> in the NT display list.</p><p>But what happens if the file has no permissions allowed for a particular UNIX user group or world component? In order
+ to allow &#8220;<span class="quote">no permissions</span>&#8221; to be seen and modified Samba then overloads the NT <tt class="constant">Take Ownership</tt> ACL attribute
+ (which has no meaning in UNIX) and reports a component with no permissions as having the NT <b class="command">O</b> bit set.
+ This was chosen, of course, to make it look like a zero, meaning zero permissions. More details on the decision behind this is
+ given below.</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2914471"></a>Directory Permissions</h4></div></div><div></div></div><p>Directories on an NT NTFS file system have two different sets of permissions. The first set is the ACL set on the
+ directory itself, which is usually displayed in the first set of parentheses in the normal <tt class="constant">RW</tt>
+ NT style. This first set of permissions is created by Samba in exactly the same way as normal file permissions are, described
+ above, and is displayed in the same way.</p><p>The second set of directory permissions has no real meaning in the UNIX permissions world and represents the <tt class="constant">
+ inherited</tt> permissions that any file created within this directory would inherit.</p><p>Samba synthesises these inherited permissions for NT by returning as an NT ACL the UNIX permission mode that a new file
+ created by Samba on this share would receive.</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2914515"></a>Modifying File or Directory Permissions</h3></div></div><div></div></div><p>Modifying file and directory permissions is as simple
+ as changing the displayed permissions in the dialog box, and
+ clicking on <span class="guibutton">OK</span>. However, there are
+ limitations that a user needs to be aware of, and also interactions
+ with the standard Samba permission masks and mapping of DOS
+ attributes that need to also be taken into account.</p><p>If the parameter <a class="indexterm" name="id2914543"></a><i class="parameter"><tt>nt acl support</tt></i>
+ is set to <tt class="constant">false</tt>, any attempt to set
+ security permissions will fail with an <span class="errorname">`Access Denied'
+ </span> message.</p><p>The first thing to note is that the <span class="guibutton">Add</span>
+ button will not return a list of users in Samba (it will give
+ an error message saying <span class="errorname">`The remote procedure call failed
+ and did not execute'</span>). This means that you can only
+ manipulate the current user/group/world permissions listed in
+ the dialog box. This actually works quite well as these are the
+ only permissions that UNIX actually has.</p><p>If a permission triplet (either user, group, or world)
+ is removed from the list of permissions in the NT dialog box,
+ then when the <span class="guibutton">OK</span> button is pressed it will
+ be applied as &#8220;<span class="quote">no permissions</span>&#8221; on the UNIX side. If you then
+ view the permissions again, the &#8220;<span class="quote">no permissions</span>&#8221; entry will appear
+ as the NT <b class="command">O</b> flag, as described above. This
+ allows you to add permissions back to a file or directory once
+ you have removed them from a triplet component.</p><p>As UNIX supports only the &#8220;<span class="quote">r</span>&#8221;, &#8220;<span class="quote">w</span>&#8221; and &#8220;<span class="quote">x</span>&#8221; bits of
+ an NT ACL, if other NT security attributes such as <tt class="constant">Delete Access</tt> are
+ selected they will be ignored when applied on the Samba server.</p><p>When setting permissions on a directory, the second
+ set of permissions (in the second set of parentheses) is
+ by default applied to all files within that directory. If this
+ is not what you want, you must uncheck the <span class="guilabel">Replace
+ permissions on existing files</span> checkbox in the NT
+ dialog before clicking on <span class="guibutton">OK</span>.</p><p>If you wish to remove all permissions from a
+ user/group/world component, you may either highlight the
+ component and click on the <span class="guibutton">Remove</span> button,
+ or set the component to only have the special <tt class="constant">Take
+ Ownership</tt> permission (displayed as <b class="command">O
+ </b>) highlighted.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2914698"></a>Interaction with the Standard Samba &#8220;<span class="quote">create mask</span>&#8221; Parameters</h3></div></div><div></div></div><p>There are four parameters that control interaction with the standard Samba <i class="parameter"><tt>create mask</tt></i> parameters.
+ These are:
+
+ </p><div class="itemizedlist"><ul type="disc"><li><a class="indexterm" name="id2914726"></a><i class="parameter"><tt>security mask</tt></i></li><li><a class="indexterm" name="id2914742"></a><i class="parameter"><tt>force security mode</tt></i></li><li><a class="indexterm" name="id2914757"></a><i class="parameter"><tt>directory security mask</tt></i></li><li><a class="indexterm" name="id2914773"></a><i class="parameter"><tt>force directory security mode</tt></i></li></ul></div><p>
+
+ </p><p>Once a user clicks on <span class="guibutton">OK</span> to apply the
+ permissions, Samba maps the given permissions into a user/group/world
+ r/w/x triplet set, and then checks the changed permissions for a
+ file against the bits set in the
+ <a class="indexterm" name="id2914803"></a><i class="parameter"><tt>security mask</tt></i> parameter. Any bits that
+ were changed that are not set to &#8220;<span class="quote">1</span>&#8221; in this parameter are left alone
+ in the file permissions.</p><p>Essentially, zero bits in the <a class="indexterm" name="id2914828"></a><i class="parameter"><tt>security mask</tt></i>
+ may be treated as a set of bits the user is <span class="emphasis"><em>not</em></span>
+ allowed to change, and one bits are those the user is allowed to change.
+ </p><p>If not explicitly set, this parameter defaults to the same value as
+ the <a class="indexterm" name="id2914853"></a><i class="parameter"><tt>create mask</tt></i> parameter. To allow a user to modify all the
+ user/group/world permissions on a file, set this parameter to 0777.
+ </p><p>Next Samba checks the changed permissions for a file against the bits set in the
+ <a class="indexterm" name="id2914875"></a><i class="parameter"><tt>force security mode</tt></i> parameter. Any bits
+ that were changed that correspond to bits set to &#8220;<span class="quote">1</span>&#8221; in this parameter
+ are forced to be set.</p><p>Essentially, bits set in the <i class="parameter"><tt>force security mode</tt></i> parameter
+ may be treated as a set of bits that, when modifying security on a file, the user has always set to be &#8220;<span class="quote">on</span>&#8221;.</p><p>If not explicitly set, this parameter defaults to the same value
+ as the <a class="indexterm" name="id2914918"></a><i class="parameter"><tt>force create mode</tt></i> parameter.
+ To allow a user to modify all the user/group/world permissions on a file
+ with no restrictions set this parameter to 000. The
+ <a class="indexterm" name="id2914935"></a><i class="parameter"><tt>security mask</tt></i> and <i class="parameter"><tt>force
+ security mode</tt></i> parameters are applied to the change
+ request in that order.</p><p>For a directory, Samba will perform the same operations as
+ described above for a file except it uses the parameter <i class="parameter"><tt>
+ directory security mask</tt></i> instead of <i class="parameter"><tt>security
+ mask</tt></i>, and <i class="parameter"><tt>force directory security mode
+ </tt></i> parameter instead of <i class="parameter"><tt>force security mode
+ </tt></i>.</p><p>The <a class="indexterm" name="id2914996"></a><i class="parameter"><tt>directory security mask</tt></i> parameter
+ by default is set to the same value as the <i class="parameter"><tt>directory mask
+ </tt></i> parameter and the <i class="parameter"><tt>force directory security
+ mode</tt></i> parameter by default is set to the same value as
+ the <a class="indexterm" name="id2915027"></a><i class="parameter"><tt>force directory mode</tt></i> parameter.
+ In this way Samba enforces the permission restrictions that
+ an administrator can set on a Samba share, while still allowing users
+ to modify the permission bits within that restriction.</p><p>If you want to set up a share that allows users full control
+ in modifying the permission bits on their files and directories and
+ does not force any particular bits to be set &#8220;<span class="quote">on</span>&#8221;, then set the following
+ parameters in the <tt class="filename">smb.conf</tt> file in that share-specific section:
+ </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>security mask = 0777</tt></i></td></tr><tr><td><i class="parameter"><tt>force security mode = 0</tt></i></td></tr><tr><td><i class="parameter"><tt>directory security mask = 0777</tt></i></td></tr><tr><td><i class="parameter"><tt>force directory security mode = 0</tt></i></td></tr></table></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2915106"></a>Interaction with the Standard Samba File Attribute Mapping</h3></div></div><div></div></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Samba maps some of the DOS attribute bits (such as &#8220;<span class="quote">read
+ only</span>&#8221;) into the UNIX permissions of a file. This means there can
+ be a conflict between the permission bits set via the security
+ dialog and the permission bits set by the file attribute mapping.
+ </p></div><p>If a file has no UNIX read access for the owner, it will show up
+ as &#8220;<span class="quote">read only</span>&#8221; in the standard file attributes tabbed dialog.
+ Unfortunately, this dialog is the same one that contains the security information
+ in another tab.</p><p>What this can mean is that if the owner changes the permissions
+ to allow himself read access using the security dialog, clicks on
+ <span class="guibutton">OK</span> to get back to the standard attributes tab
+ dialog, and clicks on <span class="guibutton">OK</span> on that dialog, then
+ NT will set the file permissions back to read-only (as that is what
+ the attributes still say in the dialog). This means that after setting
+ permissions and clicking on <span class="guibutton">OK</span> to get back to the
+ attributes dialog, you should always press <span class="guibutton">Cancel</span>
+ rather than <span class="guibutton">OK</span> to ensure that your changes
+ are not overridden.</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2915195"></a>Common Errors</h2></div></div><div></div></div><p>
+File, directory and share access problems are common on the mailing list. The following
+are examples taken from the mailing list in recent times.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2915209"></a>Users Cannot Write to a Public Share</h3></div></div><div></div></div><p>
+ &#8220;<span class="quote">
+ We are facing some troubles with file/directory permissions. I can log on the domain as admin user(root),
+ and there's a public share on which everyone needs to have permission to create/modify files, but only
+ root can change the file, no one else can. We need to constantly go to the server to
+ <b class="userinput"><tt>chgrp -R users *</tt></b> and <b class="userinput"><tt>chown -R nobody *</tt></b> to allow others users to change the file.
+ </span>&#8221;
+ </p><p>
+ There are many ways to solve this problem and here are a few hints:
+ </p><div class="procedure"><ol type="1"><li><p>
+ Go to the top of the directory that is shared.
+ </p></li><li><p>
+ Set the ownership to what ever public owner and group you want
+</p><pre class="screen">
+<tt class="prompt">$ </tt>find 'directory_name' -type d -exec chown user.group {}\;
+<tt class="prompt">$ </tt>find 'directory_name' -type d -exec chmod 6775 'directory_name'
+<tt class="prompt">$ </tt>find 'directory_name' -type f -exec chmod 0775 {} \;
+<tt class="prompt">$ </tt>find 'directory_name' -type f -exec chown user.group {}\;
+</pre><p>
+ </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ The above will set the <tt class="constant">sticky bit</tt> on all directories. Read your
+ UNIX/Linux man page on what that does. It causes the OS to assign
+ to all files created in the directories the ownership of the
+ directory.
+ </p></div></li><li><p>
+
+ Directory is: <i class="replaceable"><tt>/foodbar</tt></i>
+</p><pre class="screen">
+<tt class="prompt">$ </tt><b class="userinput"><tt>chown jack.engr /foodbar</tt></b>
+</pre><p>
+ </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ </p><p>This is the same as doing:</p><p>
+</p><pre class="screen">
+<tt class="prompt">$ </tt><b class="userinput"><tt>chown jack /foodbar</tt></b>
+<tt class="prompt">$ </tt><b class="userinput"><tt>chgrp engr /foodbar</tt></b>
+</pre><p>
+ </p></div></li><li><p>Now type:
+
+</p><pre class="screen">
+<tt class="prompt">$ </tt><b class="userinput"><tt>chmod 6775 /foodbar</tt></b>
+<tt class="prompt">$ </tt><b class="userinput"><tt>ls -al /foodbar/..</tt></b>
+</pre><p>
+
+ </p><p>You should see:
+</p><pre class="screen">
+drwsrwsr-x 2 jack engr 48 2003-02-04 09:55 foodbar
+</pre><p>
+ </p></li><li><p>Now type:
+</p><pre class="screen">
+<tt class="prompt">$ </tt><b class="userinput"><tt>su - jill</tt></b>
+<tt class="prompt">$ </tt><b class="userinput"><tt>cd /foodbar</tt></b>
+<tt class="prompt">$ </tt><b class="userinput"><tt>touch Afile</tt></b>
+<tt class="prompt">$ </tt><b class="userinput"><tt>ls -al</tt></b>
+</pre><p>
+ </p><p>
+ You should see that the file <tt class="filename">Afile</tt> created by Jill will have ownership
+ and permissions of Jack, as follows:
+</p><pre class="screen">
+-rw-r--r-- 1 jack engr 0 2003-02-04 09:57 Afile
+</pre><p>
+ </p></li><li><p>
+ Now in your <tt class="filename">smb.conf</tt> for the share add:
+ </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>force create mode = 0775</tt></i></td></tr><tr><td><i class="parameter"><tt>force direcrtory mode = 6775</tt></i></td></tr></table><p>
+ </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ These procedures are needed only if your users are not members of the group
+ you have used. That is if within the OS do not have write permission on the directory.
+ </p></div><p>
+ An alternative is to set in the <tt class="filename">smb.conf</tt> entry for the share:
+ </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>force user = jack</tt></i></td></tr><tr><td><i class="parameter"><tt>force group = engr</tt></i></td></tr></table><p>
+ </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2915635"></a>File Operations Done as <span class="emphasis"><em>root</em></span> with <span class="emphasis"><em>force user</em></span> Set</h3></div></div><div></div></div><p>
+ When you have a user in <a class="indexterm" name="id2915654"></a><i class="parameter"><tt>admin users</tt></i>, Samba will always do file operations for
+ this user as <span class="emphasis"><em>root</em></span>, even if <a class="indexterm" name="id2915674"></a><i class="parameter"><tt>force user</tt></i> has been set.
+ </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2915690"></a>MS Word with Samba Changes Owner of File</h3></div></div><div></div></div><p>
+ <span class="emphasis"><em>Question:</em></span> &#8220;<span class="quote">When user B saves a word document that is owned by user A the updated file is now owned by user B.
+ Why is Samba doing this? How do I fix this?</span>&#8221;
+ </p><p>
+ <span class="emphasis"><em>Answer:</em></span> Word does the following when you modify/change a Word document: MS Word creates a NEW document with
+ a temporary name, Word then closes the old document and deletes it, Word then renames the new document to the original document name.
+ There is no mechanism by which Samba can in any way know that the new document really should be owned by the owners
+ of the original file. Samba has no way of knowing that the file will be renamed by MS Word. As far as Samba is able
+ to tell, the file that gets created is a NEW file, not one that the application (Word) is updating.
+ </p><p>
+ There is a work-around to solve the permissions problem. That work-around involves understanding how you can manage file
+ system behavior from within the <tt class="filename">smb.conf</tt> file, as well as understanding how UNIX file systems work. Set on the directory
+ in which you are changing Word documents: <b class="command">chmod g+s `directory_name'</b> This ensures that all files will
+ be created with the group that owns the directory. In <tt class="filename">smb.conf</tt> share declaration section set:
+ </p><p>
+ </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>force create mode = 0660</tt></i></td></tr><tr><td><i class="parameter"><tt>force directory mode = 0770</tt></i></td></tr></table><p>
+ </p><p>
+ These two settings will ensure that all directories and files that get created in the share will be read/writable by the
+ owner and group set on the directory itself.
+ </p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="locking.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 12. Group Mapping MS Windows and UNIX </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 14. File and Record Locking</td></tr></table></div></body></html>