Bug 13809 – "Unix perms" Group Write permissions getting lost to client when accessing files with "zfsacl" VFS enabled

Bug 13809 - "Unix perms" Group Write permissions getting lost to client when accessing files with "zfsacl" VFS enabled


Summary:	"Unix perms" Group Write permissions getting lost to client when accessing fi...

Status:	NEW

Product:	Samba 4.1 and newer
Classification:	Unclassified
Component:	VFS Modules
Version:	4.9.4
Hardware:	x64 FreeBSD

Importance:	P5 normal
Target Milestone:	---
Assigned To:	Samba QA Contact
QA Contact:	Samba QA Contact

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2019-02-27 20:19 UTC by Peter Eriksson
Modified:	2019-02-27 21:28 UTC (History)
CC List:	0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Peter Eriksson 2019-02-27 20:19:28 UTC

We just noticed an annoying misfeature with smbd...

If you have "vfs objects" enabled (even an empty list) in smb.conf then Windows clients trying to access files and/or attempting to read the security permissions of an object protected just with plain Unix permission bits (no ACL) will find that any Group Write permissions silently will be lost. If you disable the "vfs objects" feature (comment-out or remove completely) then things work correctly...


The output from smbcacls also look a bit funny:


With 'vfs objects' enabled, server on FreeBSD:

% /liu/bin/smbcacls -k -m SMB3 //filur00/tmp test/hello.txt
REVISION:1
CONTROL:SR|DP
OWNER:AD\peter86
GROUP:AD\UF-ITI-All
ACL:AD\peter86:ALLOWED/0x0/RWPO
ACL:AD\UF-ITI-All:ALLOWED/0x0/0x0012008f
ACL:Everyone:ALLOWED/0x0/0x00120088


Server on Linux (CentOS 7, with 'vfs objects' enabled):

% smbcacls -k -m SMB3 -U peter86 //probe-g.it.liu.se/tmp test/hello.txt
REVISION:1
CONTROL:SR|PD|DP
OWNER:AD\peter86
GROUP:AD\employee-liu.se
ACL:AD\peter86:ALLOWED/0x0/0x001e01ff
ACL:AD\employee-liu.se:ALLOWED/0x0/0x001e01ff
ACL:Everyone:ALLOWED/0x0/


With no 'vfs objects' in the smb.conf file things look right:

% /liu/bin/smbcacls -k -m SMB3 //filur00/tmp test/hello.txt
REVISION:1
CONTROL:SR|PD|DP
OWNER:AD\peter86
GROUP:AD\uf-iti-all
ACL:AD\peter86:ALLOWED/0x0/RW
ACL:AD\uf-iti-all:ALLOWED/0x0/RW
ACL:Everyone:ALLOWED/0x0/


Directory on the FreeBSD server:
# ls -la /tmp/test
total 50
drwxrwx---   2 peter86  uf-iti-all   3 Feb 27 11:27 .
drwxrwxrwt  10 root     wheel       56 Feb 27 21:10 ..
-rw-rw----   1 peter86  uf-iti-all   6 Feb 27 11:27 hello.txt


Directory on the CentOS server:
# ls -la /tmp/test
total 8
drwxrwx---   2 peter86 employee-liu.se   23 Feb 27 21:15 .
drwxrwxrwt. 12 root    root            4096 Feb 27 21:17 ..
-rwxrwx---   1 peter86 employee-liu.se    6 Feb 27 21:15 hello.txt


We see this behaviour on atleast Samba 4.9.4 on FreeBSD 11.2 and Samba 4.8.3 on CentOS 7.

Comment 1 Peter Eriksson 2019-02-27 21:27:04 UTC

Hmm... A drat. I forgot that comments can only be started at the beginning of a line in the config file. (I've been burned by it before).

vfs objects = ;; shadow_copy2 zfsacl full_audit

doesn't do quite what I thought. :-)

Anyway, it seems the culprit is the "zfsacl" vfs module. With it enabled I see this behaviour for non-ACL-protected folders (on a ZFS filesystem) on our FreeBSD-with-ZFS servers.