samba - Aug 2009 - Question concerning file permissions in Samba 3.3.4

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...

Here is our smb.conf:


[global]
        workgroup = WORKGROUP
        realm = REALM
        server string = storage
        interfaces = eth0
        bind interfaces only = Yes
        security = ADS
        allow trusted domains = No
        password server = passwordserver
        username map = /usr/local/samba/lib/smbusers
        use kerberos keytab = Yes
        log file = /var/log/samba/%m.log
        ;server signing = auto
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
        load printers = No
        printcap name = /etc/printcap
        dns proxy = No
        idmap alloc backend = tdb
        idmap backend = rid:WORKGROUP=16777216-33554431
        idmap uid = 16777216-33554431
        idmap gid = 16777216-33554431
        template homedir = /home/%U
        winbind use default domain = No
        cups options = raw
        smb ports = 445



[array2]
        comment = "Disk Array 2"
        path = /mnt/array2
        read only = No
        admin users = admindude1
        inherit acls = yes
        map acl inherit = yes
[array3]
        comment = "Disk Array 3"
        path = /mnt/array3
        read only = No
        admin users = admindude1
        inherit acls = yes
        map acl inherit = yes


Thanks,

Bill Dorrian
Unix/Linux Systems Support
(904) 232-2742

"I did not get my Spaghetti-O's. I got spaghetti. I want the press to
know
this."
- Thomas J. Grasso, executed by lethal injection on March 20, 1995

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