summaryrefslogtreecommitdiff
path: root/docs/htmldocs/unix-permissions.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/unix-permissions.html')
-rw-r--r--docs/htmldocs/unix-permissions.html194
1 files changed, 0 insertions, 194 deletions
diff --git a/docs/htmldocs/unix-permissions.html b/docs/htmldocs/unix-permissions.html
deleted file mode 100644
index e9a3b5e671..0000000000
--- a/docs/htmldocs/unix-permissions.html
+++ /dev/null
@@ -1,194 +0,0 @@
-<!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 11. UNIX Permission Bits and Windows NT Access Control Lists</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.59.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="passdb.html" title="Chapter 10. User information database"><link rel="next" href="groupmapping.html" title="Chapter 12. Configuring Group Mapping"></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 11. UNIX Permission Bits and Windows NT Access Control Lists</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="passdb.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="groupmapping.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><h2 class="title"><a name="unix-permissions"></a>Chapter 11. UNIX Permission Bits and Windows NT Access Control Lists</h2></div><div><div class="author"><h3 class="author">Jeremy Allison</h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt>&lt;<a href="mailto:jra@samba.org">jra@samba.org</a>&gt;</tt></p></div></div></div></div><div><p class="pubdate">12 Apr 1999</p></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="unix-permissions.html#id2881950">Viewing and changing UNIX permissions using the NT
- security dialogs</a></dt><dt><a href="unix-permissions.html#id2881832">How to view file security on a Samba share</a></dt><dt><a href="unix-permissions.html#id2885176">Viewing file ownership</a></dt><dt><a href="unix-permissions.html#id2885297">Viewing file or directory permissions</a></dt><dd><dl><dt><a href="unix-permissions.html#id2885379">File Permissions</a></dt><dt><a href="unix-permissions.html#id2885483">Directory Permissions</a></dt></dl></dd><dt><a href="unix-permissions.html#id2885533">Modifying file or directory permissions</a></dt><dt><a href="unix-permissions.html#id2885693">Interaction with the standard Samba create mask
- parameters</a></dt><dt><a href="unix-permissions.html#id2886008">Interaction with the standard Samba file attribute
- mapping</a></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2881950"></a>Viewing and changing UNIX permissions using the NT
- security dialogs</h2></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="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2881832"></a>How to view file security on a Samba share</h2></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="emphasis"><em>Properties</em></span> entry at the bottom of
- the menu. This brings up the file properties dialog
- box. Click on the tab <span class="emphasis"><em>Security</em></span> and you
- will see three buttons, <span class="emphasis"><em>Permissions</em></span>,
- <span class="emphasis"><em>Auditing</em></span>, and <span class="emphasis"><em>Ownership</em></span>.
- The <span class="emphasis"><em>Auditing</em></span> button will cause either
- an error message A requested privilege is not held
- by the client 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 <b>Add</b> button will not currently
- allow a list of users to be seen.</p></div><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2885176"></a>Viewing file ownership</h2></div></div><p>Clicking on the <b>&quot;Ownership&quot;</b> button
- brings up a dialog box telling you who owns the given file. The
- owner name will be of the form :</p><p><b>&quot;SERVER\user (Long name)&quot;</b></p><p>Where <i><tt>SERVER</tt></i> is the NetBIOS name of
- the Samba server, <i><tt>user</tt></i> is the user name of
- the UNIX user who owns the file, and <i><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 <b>Close
- </b> button to remove this dialog.</p><p>If the parameter <i><tt>nt acl support</tt></i>
- is set to <tt>false</tt> then the file owner will
- be shown as the NT user <b>&quot;Everyone&quot;</b>.</p><p>The <b>Take Ownership</b> 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="emphasis"><em>Seclib
- </em></span> NT security library written by Jeremy Allison of
- the Samba Team, available from the main Samba ftp site.</p></div><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2885297"></a>Viewing file or directory permissions</h2></div></div><p>The third button is the <b>&quot;Permissions&quot;</b>
- 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>&quot;SERVER\user (Long name)&quot;</b></p><p>Where <i><tt>SERVER</tt></i> is the NetBIOS name of
- the Samba server, <i><tt>user</tt></i> is the user name of
- the UNIX user who owns the file, and <i><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><tt>nt acl support</tt></i>
- is set to <tt>false</tt> then the file owner will
- be shown as the NT user <b>&quot;Everyone&quot;</b> and the
- permissions will be shown as NT &quot;Full Control&quot;.</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="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="id2885379"></a>File Permissions</h3></div></div><p>The standard UNIX user/group/world triple and
- the corresponding &quot;read&quot;, &quot;write&quot;, &quot;execute&quot; 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 <b>Everyone</b>, followed
- by the list of permissions allowed for UNIX world. The UNIX
- owner and group permissions are displayed as an NT
- <b>user</b> icon and an NT <b>local
- group</b> 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 <b>&quot;read&quot;</b>, <b>
- &quot;change&quot;</b> or <b>&quot;full control&quot;</b> then
- usually the permissions will be prefixed by the words <b>
- &quot;Special Access&quot;</b> 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 &quot;no permissions&quot; to be seen and modified then Samba
- overloads the NT <b>&quot;Take Ownership&quot;</b> ACL attribute
- (which has no meaning in UNIX) and reports a component with
- no permissions as having the NT <b>&quot;O&quot;</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="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="id2885483"></a>Directory Permissions</h3></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 <b>&quot;RW&quot;</b>
- 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 <b>
- &quot;inherited&quot;</b> 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="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2885533"></a>Modifying file or directory permissions</h2></div></div><p>Modifying file and directory permissions is as simple
- as changing the displayed permissions in the dialog box, and
- clicking the <b>OK</b> 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><tt>nt acl support</tt></i>
- is set to <tt>false</tt> then any attempt to set
- security permissions will fail with an <b>&quot;Access Denied&quot;
- </b> message.</p><p>The first thing to note is that the <b>&quot;Add&quot;</b>
- button will not return a list of users in Samba (it will give
- an error message of <b>&quot;The remote procedure call failed
- and did not execute&quot;</b>). 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 <b>&quot;OK&quot;</b> button is pressed it will
- be applied as &quot;no permissions&quot; on the UNIX side. If you then
- view the permissions again the &quot;no permissions&quot; entry will appear
- as the NT <b>&quot;O&quot;</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 &quot;r&quot;, &quot;w&quot; and &quot;x&quot; bits of
- an NT ACL then if other NT security attributes such as &quot;Delete
- access&quot; 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 <b>&quot;Replace
- permissions on existing files&quot;</b> checkbox in the NT
- dialog before clicking <b>&quot;OK&quot;</b>.</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 <b>&quot;Remove&quot;</b> button,
- or set the component to only have the special <b>&quot;Take
- Ownership&quot;</b> permission (displayed as <b>&quot;O&quot;
- </b>) highlighted.</p></div><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2885693"></a>Interaction with the standard Samba create mask
- parameters</h2></div></div><p>There are four parameters
- to control interaction with the standard Samba create mask parameters.
- These are :</p><p><i><tt>security mask</tt></i></p><p><i><tt>force security mode</tt></i></p><p><i><tt>directory security mask</tt></i></p><p><i><tt>force directory security mode</tt></i></p><p>Once a user clicks <b>&quot;OK&quot;</b> 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><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><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><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><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><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><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><tt>security mask</tt></i> and <i><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><tt>
- directory security mask</tt></i> instead of <i><tt>security
- mask</tt></i>, and <i><tt>force directory security mode
- </tt></i> parameter instead of <i><tt>force security mode
- </tt></i>.</p><p>The <i><tt>directory security mask</tt></i> parameter
- by default is set to the same value as the <i><tt>directory mask
- </tt></i> parameter and the <i><tt>force directory security
- mode</tt></i> parameter by default is set to the same value as
- the <i><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>smb.conf</tt> file in that share specific section :</p><p><i><tt>security mask = 0777</tt></i></p><p><i><tt>force security mode = 0</tt></i></p><p><i><tt>directory security mask = 0777</tt></i></p><p><i><tt>force directory security mode = 0</tt></i></p></div><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="id2886008"></a>Interaction with the standard Samba file attribute
- mapping</h2></div></div><p>Samba maps some of the DOS attribute bits (such as &quot;read
- only&quot;) 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 &quot;read only&quot; 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
- <b>&quot;OK&quot;</b> to get back to the standard attributes tab
- dialog, and then clicks <b>&quot;OK&quot;</b> 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 <b>&quot;OK&quot;</b> to get back to the
- attributes dialog you should always hit <b>&quot;Cancel&quot;</b>
- rather than <b>&quot;OK&quot;</b> to ensure that your changes
- are not overridden.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="passdb.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="groupmapping.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 10. User information database </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 12. Configuring Group Mapping</td></tr></table></div></body></html>