diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/docbook/howto/DOMAIN_MEMBER.sgml | 13 | ||||
| -rw-r--r-- | docs/docbook/howto/NT_Security.sgml | 342 | ||||
| -rw-r--r-- | docs/htmldocs/DOMAIN_MEMBER.html | 49 | ||||
| -rw-r--r-- | docs/htmldocs/NT_Security.html | 1028 |
4 files changed, 1123 insertions, 309 deletions
diff --git a/docs/docbook/howto/DOMAIN_MEMBER.sgml b/docs/docbook/howto/DOMAIN_MEMBER.sgml index bdb8fd8635..888b801742 100644 --- a/docs/docbook/howto/DOMAIN_MEMBER.sgml +++ b/docs/docbook/howto/DOMAIN_MEMBER.sgml @@ -1,15 +1,10 @@ -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> -<book> - -<bookinfo> - <author><firstname>Jeremy</firstname><surname>Allison</surname></author> - <pubdate>7th Oct 1999</pubdate> -</bookinfo> +<article> <sect1> - <title>Joining an NT Domain with Samba 2.2</emphasis></title> + <title>Joining an NT Domain with Samba 2.2</title> <para>In order for a Samba-2 server to join an NT domain, you must first add the NetBIOS name of the Samba server to the @@ -165,4 +160,4 @@ the NIS/NT Samba</ulink>.</para> </sect1> -</book> +</article> diff --git a/docs/docbook/howto/NT_Security.sgml b/docs/docbook/howto/NT_Security.sgml new file mode 100644 index 0000000000..62550bfaa6 --- /dev/null +++ b/docs/docbook/howto/NT_Security.sgml @@ -0,0 +1,342 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> + +<article> + + +<sect1> + <title>Viewing and changing UNIX permissions using the NT + security dialogs</title> + + + <para>New in the Samba 2.0.4 release is the ability for Windows + NT clients to use their native security settings dialog box to + view and modify the underlying UNIX permissions.</para> + + <para>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.</para> + + <para>In Samba 2.0.4 and above the default value of the + parameter <ulink url="smb.conf.5.html#NTACLSUPPOR"><parameter> + nt acl support</parameter></ulink> has been changed from + <constant>false</constant> to <constant>true</constant>, so + manipulation of permissions is turned on by default.</para> +</sect1> + +<sect1> + <title>How to view file security on a Samba share</title> + + <para>From an NT 4.0 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 <emphasis>Properties</emphasis> entry at the bottom of + the menu. This brings up the normal file properties dialog + box, but with Samba 2.0.4 this will have a new tab along the top + marked <emphasis>Security</emphasis>. Click on this tab and you + will see three buttons, <emphasis>Permissions</emphasis>, + <emphasis>Auditing</emphasis>, and <emphasis>Ownership</emphasis>. + The <emphasis>Auditing</emphasis> button will cause either + an error message <errorname>A requested privilege is not held + by the client</errorname> 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 <command>Add</command> button will not currently + allow a list of users to be seen.</para> + +</sect1> +<sect1> + <title>Viewing file ownership</title> + + <para>Clicking on the <command>"Ownership"</command> button + brings up a dialog box telling you who owns the given file. The + owner name will be of the form :</para> + + <para><command>"SERVER\user (Long name)"</command></para> + + <para>Where <replaceable>SERVER</replaceable> is the NetBIOS name of + the Samba server, <replaceable>user</replaceable> is the user name of + the UNIX user who owns the file, and <replaceable>(Long name)</replaceable> + is the discriptive string identifying the user (normally found in the + GECOS field of the UNIX password database). Click on the <command>Close + </command> button to remove this dialog.</para> + + <para>If the parameter <parameter>nt acl support</parameter> + is set to <constant>false</constant> then the file owner will + be shown as the NT user <command>"Everyone"</command>.</para> + + <para>The <command>Take Ownership</command> 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 privilaged + operation in UNIX, available only to the <emphasis>root</emphasis> + 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.</para> + + <para>There is an NT chown command that will work with Samba + and allow a user with Administrator privillage connected + to a Samba 2.0.4 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 <emphasis>Seclib + </emphasis> NT security library written by Jeremy Allison of + the Samba Team, available from the main Samba ftp site.</para> + +</sect1> + +<sect1> + <title>Viewing file or directory permissions</title> + + <para>The third button is the <command>"Permissions"</command> + 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 :</para> + + <para><command>"SERVER\user (Long name)"</command></para> + + <para>Where <replaceable>SERVER</replaceable> is the NetBIOS name of + the Samba server, <replaceable>user</replaceable> is the user name of + the UNIX user who owns the file, and <replaceable>(Long name)</replaceable> + is the discriptive string identifying the user (normally found in the + GECOS field of the UNIX password database).</para> + + <para>If the parameter <parameter>nt acl support</parameter> + is set to <constant>false</constant> then the file owner will + be shown as the NT user <command>"Everyone"</command> and the + permissions will be shown as NT "Full Control".</para> + + + <para>The permissions field is displayed differently for files + and directories, so I'll describe the way file permissions + are displayed first.</para> + + <sect2> + <title>File Permissions</title> + + <para>The standard UNIX user/group/world triple and + the correspinding "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 <command>Everyone</command>, followed + by the list of permissions allowed for UNIX world. The UNIX + owner and group permissions are displayed as an NT + <command>user</command> icon and an NT <command>local + group</command> icon respectively followed by the list + of permissions allowed for the UNIX user and group.</para> + + <para>As many UNIX permission sets don't map into common + NT names such as <command>"read"</command>, <command> + "change"</command> or <command>"full control"</command> then + usually the permissions will be prefixed by the words <command> + "Special Access"</command> in the NT display list.</para> + + <para>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 <command>"Take Ownership"</command> ACL attribute + (which has no meaning in UNIX) and reports a component with + no permissions as having the NT <command>"O"</command> 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.</para> + </sect2> + + <sect2> + <title>Directory Permissions</title> + + <para>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 <command>"RW"</command> + 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.</para> + + <para>The second set of directory permissions has no real meaning + in the UNIX permissions world and represents the <command> + "inherited"</command> permissions that any file created within + this directory would inherit.</para> + + <para>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.</para> + </sect2> +</sect1> + +<sect1> + <title>Modifying file or directory permissions</title> + + <para>Modifying file and directory permissions is as simple + as changing the displayed permissions in the dialog box, and + clicking the <command>OK</command> 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.</para> + + <para>If the parameter <parameter>nt acl support</parameter> + is set to <constant>false</constant> then any attempt to set + security permissions will fail with an <command>"Access Denied" + </command> message.</para> + + <para>The first thing to note is that the <command>"Add"</command> + button will not return a list of users in Samba 2.0.4 (it will give + an error message of <command>"The remote proceedure call failed + and did not execute"</command>). 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.</para> + + <para>If a permission triple (either user, group, or world) + is removed from the list of permissions in the NT dialog box, + then when the <command>"OK"</command> 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 <command>"O"</command> 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.</para> + + <para>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.</para> + + <para>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 <command>"Replace + permissions on existing files"</command> checkbox in the NT + dialog before clicking <command>"OK"</command>.</para> + + <para>If you wish to remove all permissions from a + user/group/world component then you may either highlight the + component and click the <command>"Remove"</command> button, + or set the component to only have the special <command>"Take + Ownership"</command> permission (dsplayed as <command>"O" + </command>) highlighted.</para> +</sect1> + +<sect1> + <title>Interaction with the standard Samba create mask + parameters</title> + + <para>Note that with Samba 2.0.5 there are four new parameters + to control this interaction. These are :</para> + + <para><parameter>security mask</parameter></para> + <para><parameter>force security mode</parameter></para> + <para><parameter>directory security mask</parameter></para> + <para><parameter>force directory security mode</parameter></para> + + <para>Once a user clicks <command>"OK"</command> 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 <ulink url="smb.conf.5.html#SECURITYMASK"> + <parameter>security mask</parameter></ulink> parameter. Any bits that + were changed that are not set to '1' in this parameter are left alone + in the file permissions.</para> + + <para>Essentially, zero bits in the <parameter>security mask</parameter> + mask may be treated as a set of bits the user is <emphasis>not</emphasis> + allowed to change, and one bits are those the user is allowed to change. + </para> + + <para>If not set explicitly this parameter is set to the same value as + the <ulink url="smb.conf.5.html#CREATEMASK"><parameter>create mask + </parameter></ulink> parameter to provide compatibility with Samba 2.0.4 + where this permission change facility was introduced. To allow a user to + modify all the user/group/world permissions on a file, set this parameter + to 0777.</para> + + <para>Next Samba checks the changed permissions for a file against + the bits set in the <ulink url="smb.conf.5.html#FORCESECURITYMODE"> + <parameter>force security mode</parameter></ulink> parameter. Any bits + that were changed that correspond to bits set to '1' in this parameter + are forced to be set.</para> + + <para>Essentially, bits set in the <parameter>force security mode + </parameter> parameter may be treated as a set of bits that, when + modifying security on a file, the user has always set to be 'on'.</para> + + <para>If not set explicitly this parameter is set to the same value + as the <ulink url="smb.conf.5.html#FORCECREATEMODE"><parameter>force + create mode</parameter></ulink> parameter to provide compatibility + with Samba 2.0.4 where the permission change facility was introduced. + To allow a user to modify all the user/group/world permissions on a file, + with no restrictions set this parameter to 000.</para> + + <para>The <parameter>security mask</parameter> and <parameter>force + security mode</parameter> parameters are applied to the change + request in that order.</para> + + <para>For a directory Samba will perform the same operations as + described above for a file except using the parameter <parameter> + directory security mask</parameter> instead of <parameter>security + mask</parameter>, and <parameter>force directory security mode + </parameter> parameter instead of <parameter>force security mode + </parameter>.</para> + + <para>The <parameter>directory security mask</parameter> parameter + by default is set to the same value as the <parameter>directory mask + </parameter> parameter and the <parameter>force directory security + mode</parameter> parameter by default is set to the same value as + the <parameter>force directory mode</parameter> parameter to provide + compatibility with Samba 2.0.4 where the permission change facility + was introduced.</para> + + <para>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.</para> + + <para>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 <ulink url="smb.conf.5.html"><filename>smb.conf(5) + </filename></ulink> file in that share specific section :</para> + + <para><parameter>security mask = 0777</parameter></para> + <para><parameter>force security mode = 0</parameter></para> + <para><parameter>directory security mask = 0777</parameter></para> + <para><parameter>force directory security mode = 0</parameter></para> + + <para>As described, in Samba 2.0.4 the parameters :</para> + + <para><parameter>create mask</parameter></para> + <para><parameter>force create mode</parameter></para> + <para><parameter>directory mask</parameter></para> + <para><parameter>force directory mode</parameter></para> + + <para>were used instead of the parameters discussed here.</para> +</sect1> + +<sect1> + <title>Interaction with the standard Samba file attribute + mapping</title> + + <para>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. + </para> + + <para>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.</para> + + <para>What this can mean is that if the owner changes the permissions + to allow themselves read access using the security dialog, clicks + <command>"OK"</command> to get back to the standard attributes tab + dialog, and then clicks <command>"OK"</command> 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 <command>"OK"</command> to get back to the + attributes dialog you should always hit <command>"Cancel"</command> + rather than <command>"OK"</command> to ensure that your changes + are not overridden.</para> +</sect1> + +</article> diff --git a/docs/htmldocs/DOMAIN_MEMBER.html b/docs/htmldocs/DOMAIN_MEMBER.html index 3830c3dac6..6ae8e7a49d 100644 --- a/docs/htmldocs/DOMAIN_MEMBER.html +++ b/docs/htmldocs/DOMAIN_MEMBER.html @@ -6,62 +6,20 @@ NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD ><BODY -CLASS="BOOK" +CLASS="ARTICLE" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" ><DIV -CLASS="BOOK" -><A -NAME="AEN1" -></A -><DIV -CLASS="TITLEPAGE" -><H3 -CLASS="AUTHOR" -><A -NAME="AEN3" ->Jeremy Allison</A -></H3 -><HR></DIV -><DIV -CLASS="TOC" -><DL -><DT -><B ->Table of Contents</B -></DT -><DT -><A -HREF="#AEN7" -></A -></DT -><DD -><DL -><DT -><A -HREF="#AEN8" ->Joining an NT Domain with Samba 2.2</A -></DT -><DT -><A -HREF="#AEN71" ->Why is this better than security = server?</A -></DT -></DL -></DD -></DL -></DIV -><DIV CLASS="ARTICLE" ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A -NAME="AEN8" +NAME="AEN2" >Joining an NT Domain with Samba 2.2</A ></H1 ><P @@ -284,7 +242,7 @@ CLASS="SECT1" ><HR><H1 CLASS="SECT1" ><A -NAME="AEN71" +NAME="AEN65" >Why is this better than security = server?</A ></H1 ><P @@ -357,7 +315,6 @@ TARGET="_top" >.</P ></DIV ></DIV -></DIV ></BODY ></HTML >
\ No newline at end of file diff --git a/docs/htmldocs/NT_Security.html b/docs/htmldocs/NT_Security.html index eb4d3a2355..8615a7f0da 100644 --- a/docs/htmldocs/NT_Security.html +++ b/docs/htmldocs/NT_Security.html @@ -1,254 +1,774 @@ - - - - - - -<html><head><title>Viewing and changing UNIX permissions using the NT security dialogs in Samba 2.0.4</title> - -<link rev="made" href="mailto:samba@samba.org"> -</head> -<body> - -<hr> - -<h1>Viewing and changing UNIX permissions using the NT security dialogs in Samba 2.0.4</h1> -<h2>Jeremy Allison, Samba Team</h2> -<h2>12th April 1999</h2> - -<h1>Table of Contents </h1><p></p> - -<p><hr><p><br> -<p><center><strong>Viewing and changing UNIX permissions using the NT security dialogs</strong> </center><br> -<center><strong>-------------------------------------------------------------------</strong> </center> -<p>New in the <strong>Samba 2.0.4</strong> release is the -ability for Windows NT clients to use their native security -settings dialog box to view and modify the underlying UNIX -permissions. -<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>In Samba 2.0.4 and above the default value of the parameter -<a href="smb.conf.5.html#ntaclsupport"><strong>"nt acl support"</strong></a> has been -changed from "false" to "true", so manipulation of permissions is -turned on by default. -<p><strong>How to view file security on a Samba share</strong><br> -<strong>------------------------------------------</strong> -<p>From an NT 4.0 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 <code>Properties</code> entry at the -bottom of the menu. This brings up the normal file properties dialog -box, but with Samba 2.0.4 this will have a new tab along the top -marked <code>Security</code>. Click on this tab and you will see three buttons, -<em>Permissions</em>, <em>Auditing</em>, and <em>Ownership</em>. The <em>Auditing</em> -button will cause either an error message <code>"A requested privilege is -not held by the client"</code> 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 <code>Add</code> button -will not currently allow a list of users to be seen. -<p><strong>Viewing file ownership</strong><br> -<strong>----------------------</strong> -<p>Clicking on the <code>"Ownership"</code> button brings up a dialog box telling -you who owns the given file. The owner name will be of the form : -<p><code>"SERVER\user (Long name)"</code> -<p>Where <code>SERVER</code> is the NetBIOS name of the Samba server, <code>user</code> -is the user name of the UNIX user who owns the file, and <code>(Long name)</code> -is the discriptive string identifying the user (normally found in the -GECOS field of the UNIX password database). Click on the <code>Close</code> -button to remove this dialog. -<p>If the parameter <a href="smb.conf.5.html#ntaclsupport"><strong>"nt acl support"</strong></a> -is set to "false" then the file owner will be shown as the NT user -<code>"Everyone"</code>. -<p>The <code>Take Ownership</code> 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 privilaged operation in UNIX, available -only to the <em>root</em> 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>There is an NT chown command that will work with Samba and allow -a user with Administrator privillage connected to a Samba 2.0.4 -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 <strong>Seclib</strong> NT security library written by Jeremy -Allison of the Samba Team, available from the main Samba ftp site. -<p><strong>Viewing file or directory permissions</strong><br> -<strong>-------------------------------------</strong> -<p>The third button is the <code>"Permissions"</code> 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><code>"SERVER\user (Long name)"</code> -<p>Where <code>SERVER</code> is the NetBIOS name of the Samba server, <code>user</code> -is the user name of the UNIX user who owns the file, and <code>(Long name)</code> -is the discriptive string identifying the user (normally found in the -GECOS field of the UNIX password database). -<p>If the parameter <a href="smb.conf.5.html#ntaclsupport"><strong>"nt acl support"</strong></a> -is set to "false" then the file owner will be shown as the NT user -<code>"Everyone"</code> and the permissions will be shown as NT <code>"Full Control"</code>. -<p>The permissions field is displayed differently for files and directories, -so I'll describe the way file permissions are displayed first. -<p><strong>File Permissions</strong><br> -<strong>----------------</strong> -<p>The standard UNIX user/group/world triple and the correspinding -"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 <code>Everyone</code>, followed by the list of permissions -allowed for UNIX world. The UNIX owner and group permissions -are displayed as an NT <code>user</code> icon and an NT <code>local group</code> icon -respectively followed by the list of permissions allowed for the -UNIX user and group. -<p>As many UNIX permission sets don't map into common NT names such as -<code>"read"</code>, <code>"change"</code> or <code>"full control"</code> then usually the permissions -will be prefixed by the words <code>"Special Access"</code> in the NT display -list. -<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 <code>"Take Ownership"</code> ACL attribute (which has no meaning in -UNIX) and reports a component with no permissions as having the NT -<code>"O"</code> 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><strong>Directory Permissions</strong><br> -<strong>---------------------</strong> -<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 <code>"RW"</code> 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>The second set of directory permissions has no real meaning in the -UNIX permissions world and represents the <code>"inherited"</code> permissions -that any file created within this directory would inherit. -<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><strong>Modifying file or directory permissions</strong><br> -<strong>---------------------------------------</strong> -<p>Modifying file and directory permissions is as simple as changing -the displayed permissions in the dialog box, and clicking the <code>OK</code> -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>If the parameter <a href="smb.conf.5.html#ntaclsupport"><strong>"nt acl support"</strong></a> -is set to "false" then any attempt to set security permissions will -fail with an <code>"Access Denied"</code> message. -<p>The first thing to note is that the <code>"Add"</code> button will not return -a list of users in Samba 2.0.4 (it will give an error message of -<code>"The remote proceedure call failed and did not execute"</code>). 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>If a permission triple (either user, group, or world) is removed from -the list of permissions in the NT dialog box, then when the <code>"OK"</code> -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 <code>"O"</code> 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>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>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 <code>"Replace permissions on existing files"</code> checkbox -in the NT dialog before clicking <code>"OK"</code>. -<p>If you wish to remove all permissions from a user/group/world -component then you may either highlight the component and click -the <code>"Remove"</code> button, or set the component to only have the special -<code>"Take Ownership"</code> permission (dsplayed as <code>"O"</code>) highlighted. -<p><strong>Interaction with the standard Samba create mask parameters</strong><br> -<strong>----------------------------------------------------------</strong> -<p>Note that with Samba 2.0.5 there are four new parameters to -control this interaction. -<p>These are : -<p><code>security mask</code> -<code>force security mode</code> -<code>directory security mask</code> -<code>force directory security mode</code> -<p>Once a user clicks <code>"OK"</code> 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"><strong>"security mask"</strong></a> -parameter. Any bits that were changed that are not set to '1' -in this parameter are left alone in the file permissions. -<p>Essentially, zero bits in the <a href="smb.conf.5.html#securitymask"><strong>"security mask"</strong></a> -mask may be treated as a set of bits the user is <em>not</em> allowed to change, -and one bits are those the user is allowed to change. -<p>If not set explicitly this parameter is set to the same value as the -<a href="smb.conf.5.html#createmask"><strong>"create mask"</strong></a> parameter to provide compatibility -with Samba 2.0.4 where this permission change facility was introduced. -To allow a user to modify all the user/group/world permissions on a file, -set this parameter to 0777. -<p>Next Samba checks the changed permissions for a file against the -bits set in the <a href="smb.conf.5.html#forcesecuritymode"><strong>"force security mode"</strong></a> -parameter. Any bits that were changed that correspond to bits set -to '1' in this parameter are forced to be set. -<p>Essentially, bits set in the <a href="smb.conf.5.html#forcesecuritymode"><strong>"force security mode"</strong></a> -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>If not set explicitly this parameter is set to the same value as the -<a href="smb.conf.5.html#forcecreatemode"><strong>"force create mode"</strong></a> parameter to provide compatibility -with Samba 2.0.4 where the permission change facility was introduced. -To allow a user to modify all the user/group/world permissions on a file, -with no restrictions set this parameter to 000. -<p>The <a href="smb.conf.5.html#securitymask"><strong>"security mask"</strong></a> and -<a href="smb.conf.5.html#forcesecuritymode"><strong>"force security mode"</strong></a> parameters -are applied to the change request in that order. -<p>For a directory Samba will perform the same operations as described above -for a file except using the parameter <a href="smb.conf.5.html#directorysecuritymask"><strong>"directory security mask"</strong></a> -instead of <a href="smb.conf.5.html#securitymask"><strong>"security mask"</strong></a>, and -<a href="smb.conf.5.html#forcedirectorysecuritymode"><strong>"force directory security mode"</strong></a> parameter instead -of <a href="smb.conf.5.html#forcesecuritymode"><strong>"force security mode"</strong></a>. -<p>The <a href="smb.conf.5.html#directorysecuritymask"><strong>"directory security mask"</strong></a> -parameter by default is set to the same value as the <a href="smb.conf.5.html#directorymask"><strong>"directory mask"</strong></a> -parameter and the <a href="smb.conf.5.html#forcedirectorysecuritymode"><strong>"force directory security mode"</strong></a> -parameter by default is set to the same value as the -iurl(<strong>"force directory mode"</strong>)(smb.conf.5.html#forcedirectorymode) parameter -to provide compatibility with Samba 2.0.4 where the permission change facility was introduced. -<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>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 <a href="smb.conf.5.html"><strong>smb.conf.5</strong></a> file in -that share specific section : -<p><code>security mask = 0777</code> -<code>force security mode = 0</code> -<code>directory security mask = 0777</code> -<code>force directory security mode = 0</code> -<p>As described, in Samba 2.0.4 the parameters : -<p><code>create mask</code> -<code>force create mode</code> -<code>directory mask</code> -<code>force directory mode</code> -<p>were used instead of the parameters discussed here. -<p><strong>Interaction with the standard Samba file attribute mapping</strong><br> -<strong>----------------------------------------------------------</strong> -<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>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>What this can mean is that if the owner changes the permissions -to allow themselves read access using the security dialog, clicks -<code>"OK"</code> to get back to the standard attributes tab dialog, and -then clicks <code>"OK"</code> 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 <code>"OK"</code> to get back to the attributes dialog you -should always hit <code>"Cancel"</code> rather than <code>"OK"</code> to ensure -that your changes are not overridden. -</body> -</html> +<HTML +><HEAD +><TITLE +></TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD +><BODY +CLASS="ARTICLE" +BGCOLOR="#FFFFFF" +TEXT="#000000" +LINK="#0000FF" +VLINK="#840084" +ALINK="#0000FF" +><DIV +CLASS="ARTICLE" +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2" +>Viewing and changing UNIX permissions using the NT + security dialogs</A +></H1 +><P +>New in the Samba 2.0.4 release is the ability for Windows + NT clients to 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 +><P +>In Samba 2.0.4 and above the default value of the + parameter <A +HREF="smb.conf.5.html#NTACLSUPPOR" +TARGET="_top" +><TT +CLASS="PARAMETER" +><I +> nt acl support</I +></TT +></A +> has been changed from + <TT +CLASS="CONSTANT" +>false</TT +> to <TT +CLASS="CONSTANT" +>true</TT +>, so + manipulation of permissions is turned on by default.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN11" +>How to view file security on a Samba share</A +></H1 +><P +>From an NT 4.0 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 <I +CLASS="EMPHASIS" +>Properties</I +> entry at the bottom of + the menu. This brings up the normal file properties dialog + box, but with Samba 2.0.4 this will have a new tab along the top + marked <I +CLASS="EMPHASIS" +>Security</I +>. Click on this tab and you + will see three buttons, <I +CLASS="EMPHASIS" +>Permissions</I +>, + <I +CLASS="EMPHASIS" +>Auditing</I +>, and <I +CLASS="EMPHASIS" +>Ownership</I +>. + The <I +CLASS="EMPHASIS" +>Auditing</I +> 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 <B +CLASS="COMMAND" +>Add</B +> button will not currently + allow a list of users to be seen.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN22" +>Viewing file ownership</A +></H1 +><P +>Clicking on the <B +CLASS="COMMAND" +>"Ownership"</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 +CLASS="COMMAND" +>"SERVER\user (Long name)"</B +></P +><P +>Where <TT +CLASS="REPLACEABLE" +><I +>SERVER</I +></TT +> is the NetBIOS name of + the Samba server, <TT +CLASS="REPLACEABLE" +><I +>user</I +></TT +> is the user name of + the UNIX user who owns the file, and <TT +CLASS="REPLACEABLE" +><I +>(Long name)</I +></TT +> + is the discriptive string identifying the user (normally found in the + GECOS field of the UNIX password database). Click on the <B +CLASS="COMMAND" +>Close + </B +> button to remove this dialog.</P +><P +>If the parameter <TT +CLASS="PARAMETER" +><I +>nt acl support</I +></TT +> + is set to <TT +CLASS="CONSTANT" +>false</TT +> then the file owner will + be shown as the NT user <B +CLASS="COMMAND" +>"Everyone"</B +>.</P +><P +>The <B +CLASS="COMMAND" +>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 privilaged + operation in UNIX, available only to the <I +CLASS="EMPHASIS" +>root</I +> + 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 privillage connected + to a Samba 2.0.4 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 <I +CLASS="EMPHASIS" +>Seclib + </I +> NT security library written by Jeremy Allison of + the Samba Team, available from the main Samba ftp site.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN42" +>Viewing file or directory permissions</A +></H1 +><P +>The third button is the <B +CLASS="COMMAND" +>"Permissions"</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 +CLASS="COMMAND" +>"SERVER\user (Long name)"</B +></P +><P +>Where <TT +CLASS="REPLACEABLE" +><I +>SERVER</I +></TT +> is the NetBIOS name of + the Samba server, <TT +CLASS="REPLACEABLE" +><I +>user</I +></TT +> is the user name of + the UNIX user who owns the file, and <TT +CLASS="REPLACEABLE" +><I +>(Long name)</I +></TT +> + is the discriptive string identifying the user (normally found in the + GECOS field of the UNIX password database).</P +><P +>If the parameter <TT +CLASS="PARAMETER" +><I +>nt acl support</I +></TT +> + is set to <TT +CLASS="CONSTANT" +>false</TT +> then the file owner will + be shown as the NT user <B +CLASS="COMMAND" +>"Everyone"</B +> 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="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN57" +>File Permissions</A +></H2 +><P +>The standard UNIX user/group/world triple and + the correspinding "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 <B +CLASS="COMMAND" +>Everyone</B +>, followed + by the list of permissions allowed for UNIX world. The UNIX + owner and group permissions are displayed as an NT + <B +CLASS="COMMAND" +>user</B +> icon and an NT <B +CLASS="COMMAND" +>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 +CLASS="COMMAND" +>"read"</B +>, <B +CLASS="COMMAND" +> "change"</B +> or <B +CLASS="COMMAND" +>"full control"</B +> then + usually the permissions will be prefixed by the words <B +CLASS="COMMAND" +> "Special Access"</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 "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="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN71" +>Directory Permissions</A +></H2 +><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 +CLASS="COMMAND" +>"RW"</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 +CLASS="COMMAND" +> "inherited"</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" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN78" +>Modifying file or directory permissions</A +></H1 +><P +>Modifying file and directory permissions is as simple + as changing the displayed permissions in the dialog box, and + clicking the <B +CLASS="COMMAND" +>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 <TT +CLASS="PARAMETER" +><I +>nt acl support</I +></TT +> + is set to <TT +CLASS="CONSTANT" +>false</TT +> then any attempt to set + security permissions will fail with an <B +CLASS="COMMAND" +>"Access Denied" + </B +> message.</P +><P +>The first thing to note is that the <B +CLASS="COMMAND" +>"Add"</B +> + button will not return a list of users in Samba 2.0.4 (it will give + an error message of <B +CLASS="COMMAND" +>"The remote proceedure call failed + and did not execute"</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 +CLASS="COMMAND" +>"OK"</B +> 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 <B +CLASS="COMMAND" +>"Replace + permissions on existing files"</B +> checkbox in the NT + dialog before clicking <B +CLASS="COMMAND" +>"OK"</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 +CLASS="COMMAND" +>"Remove"</B +> button, + or set the component to only have the special <B +CLASS="COMMAND" +>"Take + Ownership"</B +> permission (dsplayed as <B +CLASS="COMMAND" +>"O" + </B +>) highlighted.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN100" +>Interaction with the standard Samba create mask + parameters</A +></H1 +><P +>Note that with Samba 2.0.5 there are four new parameters + to control this interaction. These are :</P +><P +><TT +CLASS="PARAMETER" +><I +>security mask</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>force security mode</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>directory security mask</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>force directory security mode</I +></TT +></P +><P +>Once a user clicks <B +CLASS="COMMAND" +>"OK"</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" +> + <TT +CLASS="PARAMETER" +><I +>security mask</I +></TT +></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 <TT +CLASS="PARAMETER" +><I +>security mask</I +></TT +> + mask may be treated as a set of bits the user is <I +CLASS="EMPHASIS" +>not</I +> + 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" +><TT +CLASS="PARAMETER" +><I +>create mask + </I +></TT +></A +> parameter to provide compatibility with Samba 2.0.4 + where this permission change facility was introduced. 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" +> <TT +CLASS="PARAMETER" +><I +>force security mode</I +></TT +></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 <TT +CLASS="PARAMETER" +><I +>force security mode + </I +></TT +> 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" +><TT +CLASS="PARAMETER" +><I +>force + create mode</I +></TT +></A +> parameter to provide compatibility + with Samba 2.0.4 where the permission change facility was introduced. + 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 <TT +CLASS="PARAMETER" +><I +>security mask</I +></TT +> and <TT +CLASS="PARAMETER" +><I +>force + security mode</I +></TT +> 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 <TT +CLASS="PARAMETER" +><I +> directory security mask</I +></TT +> instead of <TT +CLASS="PARAMETER" +><I +>security + mask</I +></TT +>, and <TT +CLASS="PARAMETER" +><I +>force directory security mode + </I +></TT +> parameter instead of <TT +CLASS="PARAMETER" +><I +>force security mode + </I +></TT +>.</P +><P +>The <TT +CLASS="PARAMETER" +><I +>directory security mask</I +></TT +> parameter + by default is set to the same value as the <TT +CLASS="PARAMETER" +><I +>directory mask + </I +></TT +> parameter and the <TT +CLASS="PARAMETER" +><I +>force directory security + mode</I +></TT +> parameter by default is set to the same value as + the <TT +CLASS="PARAMETER" +><I +>force directory mode</I +></TT +> parameter to provide + compatibility with Samba 2.0.4 where the permission change facility + was introduced.</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 <A +HREF="smb.conf.5.html" +TARGET="_top" +><TT +CLASS="FILENAME" +>smb.conf(5) + </TT +></A +> file in that share specific section :</P +><P +><TT +CLASS="PARAMETER" +><I +>security mask = 0777</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>force security mode = 0</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>directory security mask = 0777</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>force directory security mode = 0</I +></TT +></P +><P +>As described, in Samba 2.0.4 the parameters :</P +><P +><TT +CLASS="PARAMETER" +><I +>create mask</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>force create mode</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>directory mask</I +></TT +></P +><P +><TT +CLASS="PARAMETER" +><I +>force directory mode</I +></TT +></P +><P +>were used instead of the parameters discussed here.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN164" +>Interaction with the standard Samba file attribute + mapping</A +></H1 +><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 + <B +CLASS="COMMAND" +>"OK"</B +> to get back to the standard attributes tab + dialog, and then clicks <B +CLASS="COMMAND" +>"OK"</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 +CLASS="COMMAND" +>"OK"</B +> to get back to the + attributes dialog you should always hit <B +CLASS="COMMAND" +>"Cancel"</B +> + rather than <B +CLASS="COMMAND" +>"OK"</B +> to ensure that your changes + are not overridden.</P +></DIV +></DIV +></BODY +></HTML +>
\ No newline at end of file |