[Samba] No write permission if POSIX bits 0 on ZFS written by M$ Office - dos_mode returning r

[Nils Goroll]

Hi all,

I'd appreciate any pointers or advise regarding the following issue with files 
written by M$ Office on Samba 3.0.32 on snv_98 (OpenSolaris) on a ZFS filesystem:

samba share:

[sharename]
         read only = No
         browseable = yes
         writeable = yes

         directory mask = 0770
         create mask = 0770
         delete readonly = Yes
         acl check permissions = False
         vfs objects = zfsacl
         nfs4:mode = special

ZFS aclmode and aclinherit are both passthrough

If userA creates a M$ word file on a directory with these ACLs (note: 
inheritance) ...

drwxrwx---+  2 userA    group1        10 Nov 24 17:25 .
                  owner@:rwxpdDaARWc--s:fd-----:allow
                  group@:rwxpdDaARWc--s:fd-----:allow
            group:group2:rwxpdDaARWcCos:fd-----:allow

... the file gets properly created with these permissions (because the user's 
primary group is group3)

-rwxrwx---+  1 userA    group3     79258 Nov 24 17:26 f.xlsx
                  owner@:rwxpdDaARWc--s:-------:allow
                  group@:rwxpdDaARWc--s:-------:allow
            group:group2:rwxpdDaARWcCos:-------:allow

now userB can overwrite the file and we get the following ACL:

----rwx---+  1 userB    group3     35067 Nov 24 17:55 f.xlsx
              user:userA:rwxpdDaARWc--s:-------:allow
                  group@:rwxpdDaARWc--s:-------:allow
            group:group2:rwxpdDaARWcCos:-------:allow

userA and userB are both members of group1, 2 and 3, group3 being
their primary group.

Now *NO-ONE* can overwrite this file anymore.

The workaround is to either reset permissions or to explicitly add owner 
permissions:

   chmod A+owner@:rwxpdDaARWc--s:-------:allow <file>

It doesn't seem to matter who the owner is, as long as the owner has non-NULL 
permissions and the ACLs allow permissions for the user in question, the access 
is granted, while it is not if the owner acl does not exist.

When I reproduced the issue with debugging enabled, I noticed this section from 
the log which seemed to be relevant:

(trying to write to test/t.rtf which has the same ACL as above,
  but would allow my user write access by group):

[2008/11/24 17:04:45, 8] smbd/dosmode.c:(371)
   dos_mode: test/t.rtf
[2008/11/24 17:04:45, 8] smbd/dosmode.c:(188)
   dos_mode_from_sbuf returning r
[2008/11/24 17:04:45, 8] smbd/dosmode.c:(409)
   dos_mode returning r
[2008/11/24 17:04:45, 8] lib/util.c:(1844)
   is_in_path: test/t.rtf
[2008/11/24 17:04:45, 8] lib/util.c:(1868)
   is_in_path: match not found
[2008/11/24 17:04:45, 10] smbd/open.c:(852)
   open_match_attributes: file test/t.rtf old_dos_attr = 0x1, existing_unx_mode 
= 0100070, new_dos_attr = 0x0 returned_unx_mode = 00
[2008/11/24 17:04:45, 10] smbd/open.c:(1347)
   open_file_ntcreate: fname=test/t.rtf, after mapping access_mask=0x2019f
[2008/11/24 17:04:45, 5] smbd/open.c:(1399)
   open_file_ntcreate: write access requested for file test/t.rtf on read only file
[2008/11/24 17:04:45, 3] smbd/error.c:(106)
   error packet at smbd/nttrans.c(805) cmd=162 (SMBntcreateX) 
NT_STATUS_ACCESS_DENIED

 From the debug output, it looks like the issue was releated to dos_mode returning r


This issue resembles the old "Other user can't overwrite files written with M$ 
Office", but unfortunately the workaround

         force create mode = 0770
         force directory mode = 0770

seems *not* to work with ZFS ACLs any more.

I have googled quite intensively, but could not come up with any pointers to 
this issue on "real ACLs" (ZFS) - only for POSIX semantics.

Again, I'd very much appreciate any pointers or hints.

Nils