svn commit: samba-docs r454 - in trunk/Samba-HOWTO-Collection: .
jht at samba.org
jht at samba.org
Tue Mar 29 18:30:33 GMT 2005
Author: jht
Date: 2005-03-29 18:30:32 +0000 (Tue, 29 Mar 2005)
New Revision: 454
WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba-docs&rev=454
Log:
First installment of ACLs update.
Modified:
trunk/Samba-HOWTO-Collection/AccessControls.xml
Changeset:
Modified: trunk/Samba-HOWTO-Collection/AccessControls.xml
===================================================================
--- trunk/Samba-HOWTO-Collection/AccessControls.xml 2005-03-29 16:24:59 UTC (rev 453)
+++ trunk/Samba-HOWTO-Collection/AccessControls.xml 2005-03-29 18:30:32 UTC (rev 454)
@@ -998,8 +998,7 @@
<para>
- The permissions field is displayed differently for files and directories, so I'll describe the way file permissions
- are displayed first.
+ The permissions field is displayed differently for files and directories, both are discussed here:
</para>
<sect3>
@@ -1008,7 +1007,7 @@
<para>The standard UNIX user/group/world triplet and the corresponding <constant>read, write, execute</constant> permissions
triplets are mapped by Samba into a three element NT ACL with the <quote>r</quote>, <quote>w</quote> and <quote>x</quote> bits mapped into the corresponding
NT permissions. The UNIX world permissions are mapped into the global NT group <constant>Everyone</constant>, followed
- by the list of permissions allowed for UNIX world. The UNIX owner and group permissions are displayed as an NT
+ by the list of permissions allowed for the UNIX world. The UNIX owner and group permissions are displayed as an NT
<guiicon>user</guiicon> icon and an NT <guiicon>local group</guiicon> icon, respectively, followed by the list
of permissions allowed for the UNIX user and group.</para>
@@ -1105,7 +1104,7 @@
</para>
- <para>Once a user clicks on <guibutton>OK</guibutton> to apply the
+ <para>When a user clicks on <guibutton>OK</guibutton> to apply the
permissions, Samba maps the given permissions into a user/group/world
r/w/x triplet set, and then checks the changed permissions for a
file against the bits set in the
@@ -1196,6 +1195,80 @@
rather than <guibutton>OK</guibutton> to ensure that your changes
are not overridden.</para>
</sect2>
+
+ <sect2>
+ <title>Windows NT/200X ACLS and POSIX ACLS &smbmdash; Limitations</title>
+
+ <para>
+ Windows administrators are familiar with simple ACL controls and they typically
+ consider that UNIX user/group/other (ugo) permissions are inadequate and not
+ sufficiently fine-grained.
+ </para>
+
+ <para>
+ Competing SMB implementations differ in how they handle Windows ACLs. Samba handles
+ Windows ACLs from the perspective of UNIX file system adminsitration and thus adopts
+ the limitations of POSIX ACLs. Therefore, where POSIX ACLs lack a capability of the
+ Windows NT/200X ACLs, the POSIX semantics and limitations are imposed on the Windows
+ administrator.
+ </para>
+
+ <para>
+ POSIX ACLs present an interesting challenge to the UNIX adminsitrator and therfore a
+ force a compromise to be applied to Windows ACLs administration. POSIX ACLs are not
+ covered by an official standard, rather the latest standard is a draft standard
+ 1003.1e revision 17. This is the POSIX document on which the Samba implementation has
+ been implemented.
+ </para>
+
+ <para>
+ UNIX vendors differ in the manner in which POSIX ACLs are implemented. There are a
+ number of Linux file systems that support ACLs. Samba has to provide a way to make
+ transparent all the differences between the various implementations of POSIX ACLs.
+ The pressure for ACLs support in Samba has noticibly increased the pressure to
+ standardize ACLs support in the UNIX world.
+ </para>
+
+ <para>
+ Samba has to deal with the complicated matter of handling the challenge of the Windows
+ ACL that implements <emphasis>inheritance</emphasis>, a concept not anticipated by POSIX
+ ACLs as implemented in UNIX file systems. Samba provides support for <emphasis>masks</emphasis>
+ that permit normal ugo and ACLs functionality to be overrided. This further complicates
+ the way in which Windows ACLs must be implemented.
+ </para>
+
+ <para>
+ In examining POSIX ACLs we must consider the manner in which they operate for
+ both files and directories. File ACLs have the following significance:
+<screen>
+# file: testfile <- the file name
+# owner: jeremy <-- the file owner
+# group: users <-- the POSIX group owner
+user::rwx <-- perms for the file owner (user)
+user:tpot:r-x <-- perms for the additional user 'tpot'
+group::r-- <-- perms for the file group owner (group)
+group:engrs:r-- <-- perms for the additonal group 'engineers'
+mask:rwx <-- the mask that is 'ANDed' with groups
+other::--- <-- perms applied to everyone else (other)
+</screen>
+ Directory ACLs have the following signficance:
+<screen>
+# file: testdir <-- the directory name
+# owner: jeremy <-- the directory owner
+# group: jeremy <-- the POSIX group owner
+user::rwx <-- directory perms for owner (user)
+group::rwx <-- directory perms for owning group (group)
+mask::rwx <-- the mask that is 'ANDed' with group perms
+other:r-x <-- perms applied to everyone else (other)
+default:user::rwx <-- inherited owner perms
+default:user:tpot:rwx <-- inherited extra perms for user 'tpot'
+default:group::r-x <-- inherited group perms
+default:mask:rwx <-- inherited default mask
+default:other:--- <-- inherited permissions for everyone (other)
+</screen>
+ </para>
+
+ </sect2>
</sect1>
<sect1>
More information about the samba-cvs
mailing list