mirror of
https://github.com/samba-team/samba.git
synced 2025-02-15 05:57:49 +03:00
a1b6e7007b
These docs are needed for SWAT Support. Also, not everyone can build the docs so we do need to include them.
-
662 lines
58 KiB
HTML
662 lines
58 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
<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. Mapping MS Windows and Unix Groups"><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"><<a href="mailto:jht@samba.org">jht@samba.org</a>></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"><<a href="mailto:jra@samba.org">jra@samba.org</a>></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#id2919879">Features and Benefits</a></dt><dt><a href="AccessControls.html#id2920005">File System Access Controls</a></dt><dd><dl><dt><a href="AccessControls.html#id2920023">MS Windows NTFS Comparison with Unix File Systems</a></dt><dt><a href="AccessControls.html#id2916939">Managing Directories</a></dt><dt><a href="AccessControls.html#id2917034">File and Directory Access Control</a></dt></dl></dd><dt><a href="AccessControls.html#id2917441">Share Definition Access Controls</a></dt><dd><dl><dt><a href="AccessControls.html#id2917469">User and Group Based Controls</a></dt><dt><a href="AccessControls.html#id2917741">File and Directory Permissions Based Controls</a></dt><dt><a href="AccessControls.html#id2917987">Miscellaneous Controls</a></dt></dl></dd><dt><a href="AccessControls.html#id2922570">Access Controls on Shares</a></dt><dd><dl><dt><a href="AccessControls.html#id2922641">Share Permissions Management</a></dt></dl></dd><dt><a href="AccessControls.html#id2922940">MS Windows Access Control Lists and Unix Interoperability</a></dt><dd><dl><dt><a href="AccessControls.html#id2922948">Managing UNIX permissions Using NT Security Dialogs</a></dt><dt><a href="AccessControls.html#id2922986">Viewing File Security on a Samba Share</a></dt><dt><a href="AccessControls.html#id2923065">Viewing file ownership</a></dt><dt><a href="AccessControls.html#id2923187">Viewing File or Directory Permissions</a></dt><dt><a href="AccessControls.html#id2923415">Modifying file or directory permissions</a></dt><dt><a href="AccessControls.html#id2923567">Interaction with the standard Samba create mask
|
||
parameters</a></dt><dt><a href="AccessControls.html#id2923897">Interaction with the standard Samba file attribute
|
||
mapping</a></dt></dl></dd><dt><a href="AccessControls.html#id2923972">Common Errors</a></dt><dd><dl><dt><a href="AccessControls.html#id2923986">Users can not write to a public share</a></dt><dt><a href="AccessControls.html#id2924365">I have set force user and samba still makes root the owner of all the files
|
||
I touch!</a></dt></dl></dd></dl></div><p>
|
||
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
|
||
adminstrators are often confused regarding network access controls and what is the best way to
|
||
provide users with the type of access they need while protecting resources from the consequences
|
||
of untoward access capabilities.
|
||
</p><p>
|
||
Unix administrators frequently are not familiar 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 can not completely hide, even
|
||
though it does try to make the chasm transparent.
|
||
</p><p>
|
||
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 it should be borne in mind that Samba was created to
|
||
provide a means of interoperability and interchange of data between two operating environments
|
||
that are quite different. It was never the intent to make Unix/Linux like MS Windows NT. Instead
|
||
the purpose was an is to provide a sufficient level of exchange of data between the two environments.
|
||
What is available today extends well beyond early plans and expections, 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="id2919879"></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>
|
||
<span class="emphasis"><em>Unix File and Directory Permissions</em></span>
|
||
</p><p>
|
||
Samba honours 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 over-rides to native file
|
||
system permissions and behaviours. This can be handy and convenient
|
||
to affect behaviour 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>
|
||
</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.
|
||
Very 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>
|
||
<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 provide
|
||
this also. Sadly, few Linux paltforms 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="id2920005"></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. Firstly we should consider what the most significant differences are, then we shall 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="id2920023"></a>MS Windows NTFS Comparison with Unix File Systems</h3></div></div><div></div></div><p>
|
||
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
|
||
behaviour that differs from unix file system behaviour 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 very large extent and on top of that provides a high degree
|
||
of optional configuration to over-ride the default behaviour. We will look at some of these over-rides,
|
||
but for the greater part we will stay withing the bounds of default behaviour. Those wishing to explore
|
||
to depths of control ability should review the <tt class="filename">smb.conf</tt> man page.
|
||
</p><div class="variablelist"><p class="title"><b>File System Feature Comparison</b></p><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, 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>
|
||
MS Windows file names are generally Upper Case if made up of 8.3 (ie: 8 character file name
|
||
and 3 character extension. If longer than 8.3 file names 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 behaviour, 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:
|
||
<tt class="computeroutput">
|
||
MYFILE.TXT
|
||
MyFile.txt
|
||
myfile.txt
|
||
</tt>
|
||
So clearly, In an MS Windows file name space these three files CAN NOT co-exist! But in Unix
|
||
they can. So what should Samba do if all three are present? Answer, the one that 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>
|
||
MS Windows and DOS uses the back-slash '\' as a directory delimiter, Unix uses the forward-slash '/'
|
||
as it's directory delimiter. This is transparently handled by Samba.
|
||
</p></dd><dt><span class="term">Drive Identification</span></dt><dd><p>
|
||
MS Windows products support a notion of drive letters, like <b class="command">C:</b> to represent
|
||
disk partitions. Unix has NO concept if separate identifiers for file partitions since each
|
||
such file system is <tt class="filename">mounted</tt> to become part of the over-all directory tree.
|
||
The Unix directory tree begins at '/', just like the root of a DOS drive is specified like
|
||
<b class="command">C:\</b>.
|
||
</p></dd><dt><span class="term">File Naming Conventions</span></dt><dd><p>
|
||
MS Windows generally never experiences file names that begin with a '.', while in Unix these
|
||
are commonly found in a user's home directory. Files that begin with a '.' 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>
|
||
MS Windows make use of "links and Short-Cuts" 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 'soft links'. A hard link is something that MS Windows is NOT familiar with. It allows
|
||
one physical file to be known simulataneously 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/education.
|
||
</p></div><div xmlns:ns29="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2916939"></a>Managing Directories</h3></div></div><div></div></div><ns29:p>
|
||
There are three basic operations for managing directories, <b class="command">create, delete, rename</b>.
|
||
</ns29:p><div class="table"><a name="id2916957"></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><ns29:p>
|
||
</ns29:p></div><div xmlns:ns30="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2917034"></a>File and Directory Access Control</h3></div></div><div></div></div><p>
|
||
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><ns30:p>
|
||
Unix/Linux file and directory access permissions invloves setting three (3) primary sets of data and one (1) control set.
|
||
A Unix file listing looks as follows:-
|
||
|
||
</ns30:p><pre class="screen">
|
||
<tt class="prompt">jht@frodo:~/stuff> </tt><b class="userinput"><tt>ls -la</tt></b>
|
||
total 632
|
||
drwxr-xr-x 13 jht users 816 2003-05-12 22:56 .
|
||
drwxr-xr-x 37 jht users 3800 2003-05-12 22:29 ..
|
||
d--------- 2 jht users 48 2003-05-12 22:29 muchado00
|
||
d--x--x--x 2 jht users 48 2003-05-12 22:29 muchado01
|
||
dr-xr-xr-x 2 jht users 48 2003-05-12 22:29 muchado02
|
||
drwxrwxrwx 2 jht users 48 2003-05-12 22:29 muchado03
|
||
drw-rw-rw- 2 jht users 48 2003-05-12 22:29 muchado04
|
||
d-w--w--w- 2 jht users 48 2003-05-12 22:29 muchado05
|
||
dr--r--r-- 2 jht users 48 2003-05-12 22:29 muchado06
|
||
drwxrwxrwt 2 jht users 48 2003-05-12 22:29 muchado07
|
||
drwsrwsrwx 2 jht users 48 2003-05-12 22:29 muchado08
|
||
---------- 1 jht users 1242 2003-05-12 22:31 mydata00.lst
|
||
---x--x--x 1 jht users 1674 2003-05-12 22:33 mydata01.lst
|
||
--w--w--w- 1 jht users 7754 2003-05-12 22:33 mydata02.lst
|
||
--wx-wx-wx 1 jht users 260179 2003-05-12 22:33 mydata03.lst
|
||
-r--r--r-- 1 jht users 21017 2003-05-12 22:32 mydata04.lst
|
||
-r-xr-xr-x 1 jht users 206339 2003-05-12 22:32 mydata05.lst
|
||
-rw-rw-rw- 1 jht users 41105 2003-05-12 22:32 mydata06.lst
|
||
-rwxrwxrwx 1 jht users 19312 2003-05-12 22:32 mydata07.lst
|
||
<tt class="prompt">jht@frodo:~/stuff></tt>
|
||
</pre><ns30:p>
|
||
</ns30:p><p>
|
||
The columns above represent (from left to right): permissions, no blocks used, owner, group, size (bytes), access date, access time, file name.
|
||
</p><ns30:p>
|
||
The permissions field is made up of:
|
||
|
||
</ns30:p><pre class="programlisting">
|
||
<i><span class="comment"> JRV: Put this into a diagram of some sort</span></i>
|
||
[ type ] [ users ] [ group ] [ others ] [File, Directory Permissions]
|
||
[ d | l ] [ r w x ] [ r w x ] [ r w x ]
|
||
| | | | | | | | | | |
|
||
| | | | | | | | | | |-----> Can Execute, List files
|
||
| | | | | | | | | |-------> Can Write, Create files
|
||
| | | | | | | | |---------> Can Read, Read files
|
||
| | | | | | | |---------------> Can Execute, List files
|
||
| | | | | | |-----------------> Can Write, Create files
|
||
| | | | | |-------------------> Can Read, Read files
|
||
| | | | |-------------------------> Can Execute, List files
|
||
| | | |---------------------------> Can Write, Create files
|
||
| | |-----------------------------> Can Read, Read files
|
||
| |-----------------------------------> Is a symbolic Link
|
||
|---------------------------------------> Is a directory
|
||
</pre><ns30:p>
|
||
</ns30:p><ns30:p>
|
||
Any bit flag may be unset. An unset bit flag is the equivalent of 'Can NOT' and is represented as a '-' character.
|
||
|
||
</ns30:p><div class="example"><a name="id2917362"></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 can NOT do anything with it
|
||
</pre></div><ns30:p>
|
||
|
||
</ns30:p><p>
|
||
Additional posibilities in the [type] field are: c = character device, b = block device, p = pipe device, s = Unix Domain Socket.
|
||
</p><p>
|
||
The letters `rwxXst' set permissions for the user, group and others as: read (r), write (w), execute (or access for directories) (x),r
|
||
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 /tmp, 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 very helpful in setting up directories that 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 who's 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 can not be listed (seen) in the directory by anyone. The group can read files in the
|
||
directory but can NOT create new files. NOTE: 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="id2917441"></a>Share Definition Access Controls</h2></div></div><div></div></div><p>
|
||
The following parameters in the <tt class="filename">smb.conf</tt> file sections that define a share control or affect 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="id2917469"></a>User and Group Based Controls</h3></div></div><div></div></div><p>
|
||
User and group based controls can prove very useful. In some situations it is distinctly desirable to affect all
|
||
file system operations as if a single user is doing this, the use of the <i class="parameter"><tt>force user</tt></i> and
|
||
<i class="parameter"><tt>force group</tt></i> behaviour will achieve this. In other situations it may be necessary to affect a
|
||
paranoia level of control to ensure that only particular authorised persons will be able to access a share or
|
||
it's contents, here the use of the <i class="parameter"><tt>valid users</tt></i> or the <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, that when you leave the scene someone else will need to provide assistance and
|
||
if that person finds too great a mess, or if they do not understand what you have done then there is risk of
|
||
Samba being removed and an alternative solution being adopted.
|
||
</p><div class="table"><a name="id2917528"></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><col></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td>admin users</td><td><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>force group</td><td><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>force user</td><td><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>guest ok</td><td><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>invalid users</td><td><p>
|
||
List of users that should not be allowed to login to this service.
|
||
</p></td></tr><tr><td>only user</td><td><p>
|
||
Controls whether connections with usernames not in the user list will be allowed.
|
||
</p></td></tr><tr><td>read list</td><td><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>username</td><td><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>valid users</td><td><p>
|
||
List of users that should be allowed to login to this service.
|
||
</p></td></tr><tr><td>write list</td><td><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="id2917741"></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 the cause of mis-configuration. 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
|
||
re-instroduce them in a controlled fashion.
|
||
</p><div class="table"><a name="id2917761"></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><col></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td>create mask</td><td><p>
|
||
Refer to the <tt class="filename">smb.conf</tt> man page.
|
||
</p></td></tr><tr><td>directory mask</td><td><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>dos filemode</td><td><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>force create mode</td><td><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>force directory mode</td><td><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>force directory security mode</td><td><p>
|
||
Controls UNIX permission bits modified when a Windows NT client is manipulating UNIX permissions on a directory
|
||
</p></td></tr><tr><td>force security mode</td><td><p>
|
||
Controls UNIX permission bits modified when a Windows NT client manipulates UNIX permissions.
|
||
</p></td></tr><tr><td>hide unreadable</td><td><p>
|
||
Prevents clients from seeing the existance of files that cannot be read.
|
||
</p></td></tr><tr><td>hide unwriteable files</td><td><p>
|
||
Prevents clients from seeing the existance of files that cannot be written to. Unwriteable directories are shown as usual.
|
||
</p></td></tr><tr><td>nt acl support</td><td><p>
|
||
This parameter controls whether smbd will attempt to map UNIX permissions into Windows NT access control lists.
|
||
</p></td></tr><tr><td>security mask</td><td><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="id2917987"></a>Miscellaneous Controls</h3></div></div><div></div></div><p>
|
||
The following are documented because of the prevalence of administrators creating inadvertant barriers to file
|
||
access by not understanding the full implications of <tt class="filename">smb.conf</tt> file settings.
|
||
</p><div class="table"><a name="id2918008"></a><p class="title"><b>Table 13.4. Other Controls</b></p><table summary="Other Controls" border="1"><colgroup><col><col></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td>case sensitive, default case, short preserve case</td><td><p>
|
||
This means that all file name lookup will be done in a case sensitive manner.
|
||
Files will be created with the precise filename Samba received from the MS Windows client.
|
||
</p></td></tr><tr><td>csc policy</td><td><p>
|
||
Client Side Caching Policy - parallels MS Windows client side file caching capabilities.
|
||
</p></td></tr><tr><td>dont descend</td><td><p>
|
||
Allows to specify a comma-delimited list of directories that the server should always show as empty.
|
||
</p></td></tr><tr><td>dos filetime resolution</td><td><p>
|
||
This option is mainly used as a compatibility option for Visual C++ when used against Samba shares.
|
||
</p></td></tr><tr><td>dos filetimes</td><td><p>
|
||
DOS and Windows allows users to change file time stamps if they can write to the file. POSIX semantics prevent this.
|
||
This options allows DOS and Windows behaviour.
|
||
</p></td></tr><tr><td>fake oplocks</td><td><p>
|
||
Oplocks are the way that SMB clients get permission from a server to locally cache file operations. If a server grants an
|
||
oplock then 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>hide dot files, hide files, veto files</td><td><p>
|
||
Note: MS Windows Explorer allows over-ride of files marked as hidden so they will still be visible.
|
||
</p></td></tr><tr><td>read only</td><td><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>veto files</td><td><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="id2922570"></a>Access Controls on Shares</h2></div></div><div></div></div><p>
|
||
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 a very 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</tt> Full Control (ie: 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: <b class="userinput"><tt>tdbdump share_info.tdb</tt></b>.
|
||
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2922641"></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 environmemt.
|
||
</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2922654"></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, then from the menu
|
||
select <span class="guimenu">Computer</span>, then click on the <span class="guimenuitem">Shared Directories</span> entry.
|
||
</p></li><li><p>
|
||
Now click on the share that you wish to manage, then click on the <span class="guilabel">Properties</span> tab, next click on
|
||
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="id2922737"></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 filemanager. 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 <span class="emphasis"><em>Everyone</em></span> Full Control on the Share.
|
||
</p><p>
|
||
MS Windows 200x and later all comes 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 <tt class="filename">Control Panel ->
|
||
Administrative Tools -> Computer Management</tt>.
|
||
</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 on the menu item <span class="guimenuitem">Action</span>,
|
||
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 where already logged in with administrative privilidge 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, then type in the name of the target
|
||
Samba server in the field <span class="guilabel">Name:</span>. Now click on the <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>
|
||
Now in the right panel, double-click on the share you wish to set access control permissions on.
|
||
Then click on the tab <span class="guilabel">Share Permissions</span>. It is now possible to add access control entities
|
||
to the shared folder. Do NOT forget 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
|
||
then effectively no user will be able to access the share. This is a result of what is known as
|
||
ACL precedence. ie: Everyone with <span class="emphasis"><em>no access</em></span> means that MaryK who is part of the group
|
||
<tt class="constant">Everyone</tt> will have no access even if this user 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="id2922940"></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="id2922948"></a>Managing UNIX permissions Using NT Security Dialogs</h3></div></div><div></div></div><p>Windows NT clients can use their native security settings
|
||
dialog box to view and modify the underlying UNIX permissions.</p><p>Note that this ability is careful not to compromise
|
||
the security of the UNIX host Samba is running on, and
|
||
still obeys all the file permission rules that a Samba
|
||
administrator can set.</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 file via Samba is controlled at
|
||
the operating system file access control level. When trying to
|
||
figure out file access problems it is vitally important to identify
|
||
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="id2922986"></a>Viewing File Security on a Samba Share</h3></div></div><div></div></div><p>From an NT4/2000/XP client, single-click with the right
|
||
mouse button 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 properties dialog
|
||
box. Click on the tab <span class="guilabel">Security</span> 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="id2923065"></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 of the form :</p><p><b class="command">"SERVER\user (Long name)"</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). Click on the
|
||
<span class="guibutton">Close </span> button to remove this dialog.</p><p>If the parameter <i class="parameter"><tt>nt acl support</tt></i>
|
||
is set to <tt class="constant">false</tt> then the file owner will
|
||
be shown as the NT user <tt class="constant">"Everyone"</tt>.</p><p>The <span class="guibutton">Take Ownership</span> button will not allow
|
||
you to change the ownership of this file to yourself (clicking on
|
||
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
|
||
client this will not work with Samba at this time.</p><p>There is an NT chown 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, available from the main Samba ftp site.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2923187"></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 in the form :</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 <i class="parameter"><tt>nt acl support</tt></i>
|
||
is set to <tt class="constant">false</tt> then the file owner will
|
||
be shown as the NT user <tt class="constant">"Everyone"</tt> and the
|
||
permissions will be shown as NT "Full Control".</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="id2923278"></a>File Permissions</h4></div></div><div></div></div><p>The standard UNIX user/group/world triple and
|
||
the corresponding "read", "write", "execute" permissions
|
||
triples are mapped by Samba into a three element NT ACL
|
||
with the 'r', 'w', and 'x' 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>As many UNIX permission sets don't map into common
|
||
NT names such as <tt class="constant">read</tt>, <tt class="constant">
|
||
"change"</tt> or <tt class="constant">full control</tt> then
|
||
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 "no permissions" to be seen and modified then Samba
|
||
overloads the NT <b class="command">"Take Ownership"</b> 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 will
|
||
be given below.</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2923370"></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 of permissions
|
||
is the ACL set on the directory itself, this 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="id2923415"></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 the <span class="guibutton">OK</span> button. 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 <i class="parameter"><tt>nt acl support</tt></i>
|
||
is set to <tt class="constant">false</tt> then 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 of <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 triple (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 "no permissions" on the UNIX side. If you then
|
||
view the permissions again the "no permissions" 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 triple component.</p><p>As UNIX supports only the "r", "w" and "x" bits of
|
||
an NT ACL then if other NT security attributes such as "Delete
|
||
access" are selected then 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 <span class="guibutton">OK</span>.</p><p>If you wish to remove all permissions from a
|
||
user/group/world component then you may either highlight the
|
||
component and click 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 xmlns:ns31="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2923567"></a>Interaction with the standard Samba create mask
|
||
parameters</h3></div></div><div></div></div><ns31:p>There are four parameters
|
||
to control interaction with the standard Samba create mask parameters.
|
||
These are :
|
||
|
||
</ns31:p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>security mask</tt></i></td></tr><tr><td><i class="parameter"><tt>force security mode</tt></i></td></tr><tr><td><i class="parameter"><tt>directory security mask</tt></i></td></tr><tr><td><i class="parameter"><tt>force directory security mode</tt></i></td></tr></table><ns31:p>
|
||
|
||
</ns31:p><p>Once a user clicks <span class="guibutton">OK</span> to apply the
|
||
permissions Samba maps the given permissions into a user/group/world
|
||
r/w/x triple set, and then will check the changed permissions for a
|
||
file against the bits set in the <a href="smb.conf.5.html#SECURITYMASK" target="_top">
|
||
<i class="parameter"><tt>security mask</tt></i></a> parameter. Any bits that
|
||
were changed that are not set to '1' in this parameter are left alone
|
||
in the file permissions.</p><p>Essentially, zero bits in the <i class="parameter"><tt>security mask</tt></i>
|
||
mask 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 set explicitly this parameter is set to the same value as
|
||
the <a href="smb.conf.5.html#CREATEMASK" target="_top"><i class="parameter"><tt>create mask
|
||
</tt></i></a> 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 href="smb.conf.5.html#FORCESECURITYMODE" target="_top">
|
||
<i class="parameter"><tt>force security mode</tt></i></a> parameter. Any bits
|
||
that were changed that correspond to bits set to '1' 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 'on'.</p><p>If not set explicitly this parameter is set to the same value
|
||
as the <a href="smb.conf.5.html#FORCECREATEMODE" target="_top"><i class="parameter"><tt>force
|
||
create mode</tt></i></a> parameter.
|
||
To allow a user to modify all the user/group/world permissions on a file
|
||
with no restrictions set this parameter to 000.</p><p>The <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 using 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 <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 <i class="parameter"><tt>force directory mode</tt></i> parameter. </p><p>In this way Samba enforces the permission restrictions that
|
||
an administrator can set on a Samba share, whilst 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
|
||
doesn't force any particular bits to be set 'on', 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="id2923897"></a>Interaction with the standard Samba file attribute
|
||
mapping</h3></div></div><div></div></div><p>Samba maps some of the DOS attribute bits (such as "read
|
||
only") 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><p>One way this can show up is if a file has no UNIX read access
|
||
for the owner it will show up as "read only" in the standard
|
||
file attributes tabbed dialog. Unfortunately this dialog is
|
||
the same one that contains the security info in another tab.</p><p>What this can mean is that if the owner changes the permissions
|
||
to allow themselves read access using the security dialog, clicks
|
||
<span class="guibutton">OK</span> to get back to the standard attributes tab
|
||
dialog, and then clicks <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 <span class="guibutton">OK</span> to get back to the
|
||
attributes dialog you should always hit <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="id2923972"></a>Common Errors</h2></div></div><div></div></div><p>
|
||
File, Directory and Share access problems are very 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="id2923986"></a>Users can not write to a public share</h3></div></div><div></div></div><p>
|
||
“<span class="quote">
|
||
We are facing some troubles with file / directory permissions. I can log on the domain as admin user(root),
|
||
and theres 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 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>”
|
||
</p><p>
|
||
There are many ways to solve this problem, here are a few hints:
|
||
</p><div class="procedure"><p class="title"><b>Procedure 13.3. Example Solution:</b></p><ol type="1"><li><p>
|
||
Go to the top of the directory that is shared
|
||
</p></li><li xmlns:ns32=""><ns32:p>
|
||
Set the ownership to what ever public owner and group you want
|
||
</ns32:p><pre class="programlisting">
|
||
find 'directory_name' -type d -exec chown user.group {}\;
|
||
find 'directory_name' -type d -exec chmod 6775 'directory_name'
|
||
find 'directory_name' -type f -exec chmod 0775 {} \;
|
||
find 'directory_name' -type f -exec chown user.group {}\;
|
||
</pre><ns32:p>
|
||
</ns32:p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
|
||
The above will set the 'sticky bit' 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 xmlns:ns33=""><ns33:p>
|
||
|
||
Directory is: <i class="replaceable"><tt>/foodbar</tt></i>
|
||
</ns33:p><pre class="screen">
|
||
<tt class="prompt">$ </tt><b class="userinput"><tt>chown jack.engr /foodbar</tt></b>
|
||
</pre><ns33:p>
|
||
</ns33:p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><ns33:p>
|
||
</ns33:p><p>This is the same as doing:</p><ns33:p>
|
||
</ns33: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><ns33:p>
|
||
</ns33:p></div></li><li xmlns:ns34=""><ns34:p>Now do:
|
||
|
||
</ns34: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><ns34:p>
|
||
|
||
</ns34:p><ns34:p>You should see:
|
||
</ns34:p><pre class="screen">
|
||
drwsrwsr-x 2 jack engr 48 2003-02-04 09:55 foodbar
|
||
</pre><ns34:p>
|
||
</ns34:p></li><li xmlns:ns35=""><ns35:p>Now do:
|
||
</ns35: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><ns35:p>
|
||
</ns35:p><ns35:p>
|
||
You should see that the file <tt class="filename">Afile</tt> created by Jill will have ownership
|
||
and permissions of Jack, as follows:
|
||
</ns35:p><pre class="screen">
|
||
-rw-r--r-- 1 jack engr 0 2003-02-04 09:57 Afile
|
||
</pre><ns35:p>
|
||
</ns35:p></li><li xmlns:ns36=""><ns36:p>
|
||
Now in your <tt class="filename">smb.conf</tt> for the share add:
|
||
</ns36:p><pre class="programlisting">
|
||
force create mode = 0775
|
||
force direcrtory mode = 6775
|
||
</pre><ns36:p>
|
||
</ns36:p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
|
||
The above are only needed <span class="emphasis"><em>if</em></span> your users are <span class="emphasis"><em>not</em></span> members of the group
|
||
you have used. ie: Within the OS do not have write permission on the directory.
|
||
</p></div><ns36:p>
|
||
An alternative is to set in the <tt class="filename">smb.conf</tt> entry for the share:
|
||
</ns36:p><pre class="programlisting">
|
||
force user = jack
|
||
force group = engr
|
||
</pre><ns36:p>
|
||
</ns36:p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2924365"></a>I have set force user and samba still makes <span class="emphasis"><em>root</em></span> the owner of all the files
|
||
I touch!</h3></div></div><div></div></div><p>
|
||
When you have a user in 'admin users', samba will always do file operations for
|
||
this user as <span class="emphasis"><em>root</em></span>, even if <i class="parameter"><tt>force user</tt></i> has been set.
|
||
</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. Mapping MS Windows and Unix Groups </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>
|