Re: [Samba] Windows ACL adjustments, permission denied

2006-01-06 Thread Henrik Zagerholm
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:rw

Re: [Samba] Windows ACL adjustments, permission denied

2006-01-05 Thread 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


Re: [Samba] Windows ACL adjustments, permission denied

2006-01-04 Thread Mike Partyka
Yes, using Winbind, AD users and groups appear to be local users and groups
to the *nix box, so you can then chown/chgrp files and dirs specifying the
user/group as "DOMAIN/user". That's one way of adding AD users and groups.
You should also be able to use the Microsoft MMC, or windows explorer to do
this.

Additionally if your kernel supports POSIX ACL's and Extended attributes you
can modify any permissions in a 200X ACL that appears on: share properties
->Advanced button ->Permissions tab

I actualy spoke too soon as i was mistaken i had found the solution, i am
still having a problem doing this. The change i made allows me to apply
changes to the ACL's and i get no error, but in actuality the change is not
being made, if you reopen the share properties and look at the ACL it's
unchanged. So i still have a problem somewhere.

HTH
Mike

On 1/3/06, Adam Nielsen <[EMAIL PROTECTED]> wrote:
>
> > Once i did this, i was able to change the ACL, all i wanted. Hope
> > this saves someone some effort down the line.
>
> Just out of curiosity, what ACLs are you changing?  Because my set up
> only gives me access to the ugo/rwx UNIX permissions.  I can't add an
> arbitrary user, like DOMAIN/UserX.  Is this what you're able to do?
>
> Cheers,
> Adam.
>
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba


Re: [Samba] Windows ACL adjustments, permission denied

2006-01-03 Thread Adam Nielsen
> Once i did this, i was able to change the ACL, all i wanted. Hope
> this saves someone some effort down the line.

Just out of curiosity, what ACLs are you changing?  Because my set up
only gives me access to the ugo/rwx UNIX permissions.  I can't add an
arbitrary user, like DOMAIN/UserX.  Is this what you're able to do?

Cheers,
Adam.
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba