[Samba] File permissions issue: different behavior between samba and unix

[Eric Diven]

I'm seeing behavior that I was hoping somebody could explain.  I have a
share set up that will be a repository for company-wide data.  There are
three classes of people who can access it, readers, read/writers, and
admins.  Readers and read/writers are self explanatory, admins have
read/write access, and can change the permissions/ownership of files.

Read and write access is controlled by ACLs on the filesystem (see
below), admin access is controlled by smb.conf.  Read and admin access
works as expected.  Reader/Writer access is behaving unexpectedly.  A
writer can create a file in the share, the ownerships, permissions, and
ACLs are inherited as I expect them to be.  Now it gets strange.  

Once I've created a file, I can't rename it and get the error permission
denied.  I can write to the file itself, but not change its name or
delete it.  Yes I'm aware that rename/delete permission is a function of
the parent directory perms, not the file perms.  As I understand, file
creation requires exactly the same permissions (rwx) as rename and
delete.  Hence the unexpectedness of this.

Now it gets *REALLY* strange:

I can create, rename, and remove directories without difficulty.  I
don't get errors either renaming or deleting them.

One last bit of strangeness:

If I change the group ownership of the directory to the writer's group,
the unexpected behavior goes away.  This seems to suggest to me that
something strange is happening with the ACLs in samba in the case of
file rename or delete.

Samba version is 3.0.24, the issue is reproducible on Solaris and
CentOS.  I hesitate to call this a bug, because there could be a reason
for this, but this behavior is not consistent with how this works under
unix at the shell.  I duplicated the reader/writer permissions and acls
with a non-domain user and group, and observed the behavior I expected,
namely that I could rename and remove the file I had created.

If you want logs or further information, I can send them to you.

Thanks,

~Eric

Here are the perms and acls I've set up on the directory.  Note that the
setgid bit is set so that files created in the diretory inherit root
group 
ownership:

bash-3.00# ls -ld afiles
drwxrws---+  2 root     root         512 Nov  1 10:21 afiles

bash-3.00# getfacl afiles
# file: afiles
# owner: root
# group: root
user::rwx
user:afile:rwx          #effective:rwx
group::rwx              #effective:rwx
group:afile:rwx         #effective:rwx
group:W2K3TEST+areaders:r-x             #effective:r-x
group:W2K3TEST+awriters:rwx             #effective:rwx
group:W2K3TEST+admins:rwx               #effective:rwx
mask:rwx
other:---
default:user::rwx
default:group::rwx
default:group:W2K3TEST+areaders:r-x
default:group:W2K3TEST+awriters:rwx
default:group:W2K3TEST+admins:rwx
default:mask:rwx
default:other:---
bash-3.00#

Here is the share definition as spat back out from testparm

[afiles]
        path = /honda/afiles
        admin users = W2K3TEST+bobadmin, @W2K3TEST+admins
        read only = No
        inherit permissions = Yes
        inherit acls = Yes
        inherit owner = Yes