Nils Goroll
2008-Nov-24 17:27 UTC
[Samba] No write permission if POSIX bits 0 on ZFS written by M$ Office - dos_mode returning r
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
odi
2008-Nov-24 21:10 UTC
[Samba] No write permission if POSIX bits 0 on ZFS written by M$ Office - dos_mode returning r
Hi, I've the same problem on Solaris 10 with samba 3.0.25c, interesting to read that the problem exists also in later versions, due to the fact that I'm using zfs and samba in production I've disabled nt acls on user shared shares with nt acl support = no odi On Monday 24 November 2008 18:27:49 Nils Goroll wrote:> 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