Bug 6056 - Unable to disable ACL usage
Unable to disable ACL usage
Status: RESOLVED FIXED
Product: Samba 3.3
Classification: Unclassified
Component: VFS Modules
3.3.0rc2
x64 Solaris
: P3 regression
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-19 20:02 UTC by Jens Elkner
Modified: 2009-09-19 13:22 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Elkner 2009-01-19 20:02:43 UTC
Right now it is impossible to disable ACL usage completely for a share.
The problem occurs with zfs [mounted per lofs into a zone]: 
1) the zfsacl stack is not working at all
2) disable zfsacl has no effect, since smbd uses than Solaris aka Posix ACLs
3) Posix ACLs are not working/fail on ZFS
4) setting all *acl* directives to no has no effect - smbd still uses Solaris ACLs
[global]
...
# collected from testparm -v
        acl compatibility = auto
        acl check permissions = Yes
        acl group control = No
        acl map full control = Yes
        force unknown acl user = No
        inherit acls = No
        nt acl support = Yes
        profile acls = No
        map acl inherit = No

[office]
        comment = office
        path = /export/share/office
        valid users = @office
        force group = office
        acl check permissions = No
        acl map full control = No
        nt acl support = No
        public = no
        writable = yes
        printable = no
        create mode = 660
        directory mode = 770
        browseable = yes
        strict locking = yes

So assume User A and B and group G: If user A:G owns a file with 0660, user B:G is able to open the file (e.g. bla.xls), but is not able to save it - results in a *tmp file of size 0 set to mode 0000 including an ACL entry for rw permisson for B:G. This very basic/simple scenario (edit perms per [work]group) could be accomplished by avoiding ACLs at all (i.e. traditional UNIX file handling), however right now there is no known way to disable ACL usage.
Comment 1 Jens Elkner 2009-01-21 00:43:22 UTC
Wrt. zfsacl stack: The problem seems to occure with MS Office 2007: office seems to create a tempfile and tries to set the same ACLs as in the original file, which leads to a chown call, which tries to set user A as the file owner, which fails, because the process is not running with super-user rights:

              libc.so.1`chown+0x7
              smbd`vfswrap_chown+0x24
              smbd`try_chown+0x46
              zfsacl.so`smb_set_nt_acl_nfs4+0x575
              zfsacl.so`zfs_set_nt_acl+0x28
              zfsacl.so`zfsacl_fset_nt_acl+0x17
              smbd`set_sd+0x141
              smbd`call_nt_transact_set_security_desc+0xfc
              smbd`handle_nttrans+0x17e
              smbd`reply_nttrans+0x5e9
              smbd`switch_message+0x37e
              smbd`construct_reply+0x83
              smbd`process_smb+0x112
              smbd`smbd_process+0x179
              smbd`main+0xe11
              smbd`_start+0x7d

chown:entry chmod 27384:110 bla/4180D0D9.tmp
chown:return 1
Comment 2 Volker Lendecke 2009-07-27 05:22:34 UTC
Can you try "dos filemode = yes" with the zfs acl module?

Thanks,

Volker
Comment 3 Jens Elkner 2009-08-05 18:49:44 UTC
Not sure about 3.3.0, but the problem wrt. ZFS <--> Win ACLs was fixed by Jeremy in the 3.3.1pre tree on 2009/02/20 (see IRC log if available). So there is no need to completely disable ACLs anymore - the permissions end up as ACLs on ZFS anyway.

Gruß,
jens.
Comment 4 Karolin Seeger 2009-09-19 12:32:24 UTC
Jeremy, is that a blocker for 3.3.8?
Comment 5 Volker Lendecke 2009-09-19 13:22:31 UTC
From the comments I'd call this just fixed. Haven't tried myself though. Jens, please re-open if it is still an issue.

Volker