Snippet from http://searchopensource.techtarget.com/tip/
0,289483,sid39_gci1080966,00.html
cheers
henrik
Windows NT/200X ACLs
The following table provides a summary of the 14 key ACE flags that
are supported in Windows 2000 and later products (for example,
Windows XP Professional):
Windows ACE
File Attribute Flag
Full Control
#
Traverse Folder/Execute File
x
List Folder/Read Data
r
Read Attributes
r
Read Extended Attributes
r
Create Files/Write Data
w
Create Folders/Append Data
w
Write Attributes
w
Write Extended Attributes
w
Delete Subfolders and Files
w
Delete
#
Read Permissions
all
Change Permissions
#
Take Ownership
#
In this table, the # character means this flag is selected only when
the Full Control flag is set. The File Attribute Flag shown in the
right column shows how the Windows ACE flags are mapped to UNIX POSIX
ACL permissions of rwx for users/groups/others (ugo) and for the
extended POSIX ACLs described earlier. The reference to "all" means
that read permission can not be denied for the owner and group owner
of a UNIX file or directory.
As can be seen from the table, many Windows ACE flags have no
equivalent in the UNIX operating system space. The Samba Team was
thus compelled to map the flags in a sensible manner so as to achieve
the net desired capability to copy files and directories with
preservation of Windows ACL controls. The net result, however, is
that files copied from a Windows 200X server to a Samba server will
lose some ACL information. This is inconsequential so long as the
files are then not copied back to the Windows 200X server.
Windows ACLS are familiar to Windows network administrators because
they are the sole tool available for access control to files,
directories and shares. Windows NT/200X systems have no concept of an
inherent scheme of ownership by a user/group/other triplet. Windows
files do have a concept of an owner, but not a group owner. Access
control is entirely implemented by way of ACLs.
In fact, it is entirely possible under Windows to remove all ACEs
from the ACL. In earlier versions of Windows (3.10) it was possible
for the Windows administrator to do so, with the result that even the
administrator then could not access the affected files. The recovery
of dis-accessed files on such systems required giving the
administrator appropriate rights and privileges to permit the dis-
accessed files to be reclaimed. Such problem is not possible within
the UNIX operating system environment. Fortunately, since Windows NT4
the administrator by default has the ability to recover dis-accessed
files.
Windows ACLs are horribly complicated compared with the simplicity of
UNIX file and directory permissions and POSIX extended ACLs. Windows
ACLs were designed from a computing science perspective to provide
such complex capabilities that most Windows administrators fail to
correctly understand how best to use them. Furthermore, few Windows
programmers understand how to correctly use the ACL API, resulting in
most Windows applications not making use of ACLs as they could.
Windows ACLs are highly specific with complex orders of precedence.
One common mistake that is made by new users is to implement the
following specification (as a manager might prescibe it):
Everyone should be denied access to XYZ folder and files
Engineers should have read access
Managers should have write access
Faulty implementation:
Everyone (No Access)
Engineers (read only)
Managers (Full Control)
The problem with this specification is that all Engineers and
Managers are members of the Everyone group and will be denied access
because the global denial ACE has higher precedence than the
permission ACEs. It was necessary only to specify the ACEs for
Engineers and for Managers. The complexity of such an ACL is readily
avoided with POSIX ACLs under UNIX and therefore also with Samba
since it transparently passes all access controls through to the host
operating system.
Guidelines for the use of Windows ACLs with a Samba File Server
It is useful to consider what will happen when a Windows file is
copied to a Samba server that has ACL support.
Let us assume that a file that has the following ACL is copied by the
user "root" from a Windows server to a Samba server. It is necessary
that the domain user "root" must have a relative identifier (RID) of
500 so that this account is acknowledged under Windows as the domain
administrator.
The ACL on this hypothetical file has the following ACEs:
Owner: jht
jht has Full Control
Domain users have read control
Accountants have read and write control
Technicians have Full Control
When appropriately copied to the Samba server (using a tool such as
robocopy) the file attributes on the UNIX host server will be:
owner:jht:rwx
owner group:Domain Admins:rw-
group:Domain Users:r--
group:Accountants:rw-
group:Technicians:rwx
If the user "jht" did not exist at the time the file was copied it
will be owned by the "root" account (the valid account that created
the file).
The above information will be stored in an extended POSIX ACL. What
will hopefully be obvious by now, is that the use of an extended
POSIX ACL can be avoided entirely by the following:
Setting the owner/group/other permissions to: -rw-rw-r-- jht Technicians
i.e.: owner:jht:rw-
group owner:Technicians:r-
other::r--
By creating a security setting on the share via the MMC console from
a Windows client, an ACL can be created so that only Accountants and
Technicians can attach to the share. The resulting solution avoids
that need to use an extended POSIX ACL and yet has the same access
control as the original Windows ACL, but the benefit is that UNIX
server file access overhead will be much lower than compared with the
overhead of processing the complex ACL that was created by a simple
robocopy transfer of the file.
A factor that is not often realized by inexperienced Windows network
administrators (and certainly missed by many users) is that the
copying of Windows files using the Windows Explorer fails to copy the
originating file ACL, instead a new one is created from that which is
inherited from the directory on the target server. This happens in a
pure Windows environment as well as with Samba.
5 jan 2006 kl. 16:27 skrev Mike Partyka:
Agreed, this functionality would be great, and the Samba books says
works,
so i have to believe it's possible. I looked at the logging and
posted it on
a response to another suggestion, it refers to unknown auth type
9 ....
Looked through the archives and really didn't see any answers. WHEN
i find
it, i'll let you know :)
On 1/4/06, Lee Rocky <[EMAIL PROTECTED]> wrote:
me either,
some ACL can't changed after apply.
only ro/rw/no access can be set.
It will be great if there's an option support 200x full ACL.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
