[Samba] Question concerning file permissions in Samba 3.3.4

[Dorrian, William M Contractor ACE-IT@SAJ]

Jeremy,

Thanks for the clarification.

It turns out that I had an Active Directory permission problem, and here it
is:

A user (We'll call him "User1") was part of an Active Directory Global Group
(Which I'll call "Group1"). "Group1" is one of six Global groups which are
nested in what we call "Supergroup1" (also an Active Directory Global group).

The issue was that we recursively assigned "Full Control" permissions to
"Supergroup1" and then assumed "User1" would have "Full Control" on the files
contained within. (At first, we thought that the reason why "User1" couldn't
modify those files was because "Modify" and "Delete" couldn't be selected
when viewing at the file permissions in Windows Explorer. However, you set us
straight on that and we now know that wasn't the problem.)

The real issue is that the permissions aren't working transitively from
"Supergroup1" to "Group1" to "User1". Is there a setting that I'm missing?
Note that if we assign permissions to "Group1" on a directory, all is well
and "User1" can modify files.

Thanks again for your help,
Bill D.

 

-----Original Message-----
From: Jeremy Allison [mailto:jra at samba.org] 
Sent: Monday, August 17, 2009 5:26 PM
To: Dorrian, William M Contractor ACE-IT at SAJ
Cc: samba at lists.samba.org
Subject: Re: [Samba] Question concerning file permissions in Samba 3.3.4

On Mon, Aug 17, 2009 at 03:15:59PM -0400, Dorrian, William M  Contractor
ACE-IT at SAJ wrote:
> We're running Samba 3.3.4 on RHEL 5 Linux, using Active Directory 
> authentication.
> 
> I've noticed that we are able to assign NTFS "Full Control" 
> permissions to directories; however, we are unable to do the same on 
> the files contained within those directories. Is there a default 
> setting that is preventing us from being able to assign them? Note 
> that this happens even at the very top of the directory tree...

Ok, here is the deal. With Samba 3.3.x, we moved to using the returned
Windows permissions (as mapped from POSIX ACLs) to control all file access.
This gets us closer to Windows behavior, but there's one catch. "Full
Control" includes the ability to delete a file, but in POSIX the ability to
delete a file belongs to the containing directory, not the file itself.

So when we return the Windows permissions for a file ACL with "rwx" set, by
default we'd like to map to "Full Control" (see the default setting of the
parameter acl map full control) but we must remove the DELETE_ACCESS flag
from the mapping, as that is not a permission that is granted. Thus the ACL
editor doesn't see "DELETE_ACCESS"
in the returned ACE entry, and so doesn't believe it's "Full Control".

If we don't remove the DELETE_ACCESS bit, the client will open a file for
delete, and successfully get a file handle back, but the delete will fail
when the set file info (delete this file) call is made. Windows clients only
check the error return on the open for delete call, not the actual set file
info that allows the delete - if you fail that call Windows explorer silently
ignores the error, tells you you have deleted the file, but the file is still
there and will reappear on the next directory refresh, thus confusing users.

Hopefully this explains why we can't map completely into "Full Control" but
must remove the DELETE_ACCESS bit. It may confuse users a bit, but that's
better than confusing them when they're wondering why files they've deleted
keep coming back from the dead (trust me, people complained more about that
for a *long* time until I discovered this work-around).

Jeremy