Peter Eriksson
2025-Apr-11 13:00 UTC
[Samba] Strange permissions/ZFS ACL issue on 4.20-4.22
I?m running Samba on FreeBSD with ZFS with the vfs_zfsacl module enable to allow
real ACLs to work (with a patch to fix the O_PATH stuff). This is working fine
on versions up to (and including) 4.19.9. However from 4.20 and forward newly
created files gets the ACL wrong.
Adding some debugging code to the vfs_default and vfs_zfsacl modules I notice
that when creating a new file this happens:
vfswrap_openat(., 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
vfswrap_openat(acl0, 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
fget_zfsacl(acl0): IO: facl(27, ACE_GETACL) -> 3, 3
[2025/04/11 14:01:15.387447, 1]
../../source3/modules/vfs_zfsacl.c:442(fget_zfsacl)
facl(27[acl0], ACE_SETACL, 3, ...):
everyone@:------a-R-c---:fd-----:allow
user:peter86:rwxpDdaARWcCo-:fd-----:allow
everyone@:--------------:fd----I:allow
vfswrap_openat(, 00) [is_pathref=0, have_proc_fds=0] {O_PATH}
vfswrap_openat(acl0/e.txt, 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
vfswrap_openat(acl0, 00) [is_pathref=0, have_proc_fds=0] {O_PATH}
vfswrap_openat(, 00) [is_pathref=0, have_proc_fds=0] {O_PATH}
vfswrap_openat(acl0/e.txt, 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
vfswrap_openat(acl0/e.txt, 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
fget_zfsacl(acl0): IO: facl(8, ACE_GETACL) -> 3, 3
[2025/04/11 14:01:15.388691, 1]
../../source3/modules/vfs_zfsacl.c:442(fget_zfsacl)
facl(8[acl0], ACE_SETACL, 3, ...):
everyone@:------a-R-c---:fd-----:allow
user:peter86:rwxpDdaARWcCo-:fd-----:allow
everyone@:--------------:fd----I:allow
vfswrap_openat(acl0/e.txt, 0644) [is_pathref=0, have_proc_fds=0] {O_PATH}
vfswrap_fchmod(acl0/e.txt, mode=0644) [is_pathref=0, have_proc_fds=1]
fget_zfsacl(acl0/e.txt): IO: facl(27, ACE_GETACLCNT) -> 4
[2025/04/11 14:01:15.389854, 1]
../../source3/modules/vfs_zfsacl.c:411(fget_zfsacl)
fget_zfsacl(acl0/e.txt): IO: facl(27, ACE_GETACL) -> 4, 4
[2025/04/11 14:01:15.390038, 1]
../../source3/modules/vfs_zfsacl.c:442(fget_zfsacl)
facl(27[acl0/e.txt], ACE_SETACL, 4, ...):
user:peter86:rwxpDdaARWcCo-:------I:allow
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:r-----a-R-c--s:-------:allow
The problem is that Samba now calls vfs_fchmod() with 0644 as mode - which
causes FreeBSD to ?corrupt? (actually, FreeBSD tries its best to do that the
code tells it to do - so it tries to change the ACL of the file so that it gives
owner@ rw, group@ r and everyone@ r permissions. That call to vfs_fchmod does
not occur with Samba 4.19.9 and earlier?
A wild guess is that this change of behaviour is due to the code for
implementing smb3 unix extensions somehow (even though we have that disabled
with ?smb3 unix extensions = no? in smb.conf).
Ah well. I?ll keep on debugging this...
- Peter
Peter Eriksson
2025-Apr-11 14:39 UTC
[Samba] Strange permissions/ZFS ACL issue on 4.20-4.22
It?s this code in source3/smbd/open.c: open_file_ntcreate() that causes the
FCHMOD call:
/*
* Take care of inherited ACLs on created files - if default ACL not
* selected.
*/
if (!posix_open && new_file_created && !def_acl) {
if (unx_mode != smb_fname->st.st_ex_mode) {
int ret = SMB_VFS_FCHMOD(fsp, unx_mode);
If I remove that call then things behave better? A bit ?heavy? fix though :-)
(Seems unx_mode is not the same as st_ex_mode)
[2025/04/11 15:18:09.101781, 1]
../../source3/smbd/open.c:4294(open_file_ntcreate)
open_file_ntcreate: acl0/g.txt: Resetting via FCHMOD: posix_open=0
new_file_created=1 def_acl=0 unx_mode=0x1a4 smb_fname->st.st_ex_mode=0x81c0
- Peter
> int ret = SMB_VFS_FCHMOD(fsp, unx_mode);
> On 11 Apr 2025, at 15:00, Peter Eriksson via samba <samba at
lists.samba.org> wrote:
>
> I?m running Samba on FreeBSD with ZFS with the vfs_zfsacl module enable to
allow real ACLs to work (with a patch to fix the O_PATH stuff). This is working
fine on versions up to (and including) 4.19.9. However from 4.20 and forward
newly created files gets the ACL wrong.
>
> Adding some debugging code to the vfs_default and vfs_zfsacl modules I
notice that when creating a new file this happens:
>
> vfswrap_openat(., 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
> vfswrap_openat(acl0, 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
>
> fget_zfsacl(acl0): IO: facl(27, ACE_GETACL) -> 3, 3
>
> [2025/04/11 14:01:15.387447, 1]
../../source3/modules/vfs_zfsacl.c:442(fget_zfsacl)
> facl(27[acl0], ACE_SETACL, 3, ...):
> everyone@:------a-R-c---:fd-----:allow
> user:peter86:rwxpDdaARWcCo-:fd-----:allow
> everyone@:--------------:fd----I:allow
>
> vfswrap_openat(, 00) [is_pathref=0, have_proc_fds=0] {O_PATH}
>
> vfswrap_openat(acl0/e.txt, 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
>
> vfswrap_openat(acl0, 00) [is_pathref=0, have_proc_fds=0] {O_PATH}
>
> vfswrap_openat(, 00) [is_pathref=0, have_proc_fds=0] {O_PATH}
>
> vfswrap_openat(acl0/e.txt, 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
>
> vfswrap_openat(acl0/e.txt, 00) [is_pathref=1, have_proc_fds=0] {O_PATH}
>
> fget_zfsacl(acl0): IO: facl(8, ACE_GETACL) -> 3, 3
>
> [2025/04/11 14:01:15.388691, 1]
../../source3/modules/vfs_zfsacl.c:442(fget_zfsacl)
> facl(8[acl0], ACE_SETACL, 3, ...):
> everyone@:------a-R-c---:fd-----:allow
> user:peter86:rwxpDdaARWcCo-:fd-----:allow
> everyone@:--------------:fd----I:allow
>
> vfswrap_openat(acl0/e.txt, 0644) [is_pathref=0, have_proc_fds=0] {O_PATH}
>
> vfswrap_fchmod(acl0/e.txt, mode=0644) [is_pathref=0, have_proc_fds=1]
>
> fget_zfsacl(acl0/e.txt): IO: facl(27, ACE_GETACLCNT) -> 4
> [2025/04/11 14:01:15.389854, 1]
../../source3/modules/vfs_zfsacl.c:411(fget_zfsacl)
>
> fget_zfsacl(acl0/e.txt): IO: facl(27, ACE_GETACL) -> 4, 4
> [2025/04/11 14:01:15.390038, 1]
../../source3/modules/vfs_zfsacl.c:442(fget_zfsacl)
> facl(27[acl0/e.txt], ACE_SETACL, 4, ...):
> user:peter86:rwxpDdaARWcCo-:------I:allow
> owner@:rw-p--aARWcCos:-------:allow
> group@:r-----a-R-c--s:-------:allow
> everyone@:r-----a-R-c--s:-------:allow
>
> The problem is that Samba now calls vfs_fchmod() with 0644 as mode - which
causes FreeBSD to ?corrupt? (actually, FreeBSD tries its best to do that the
code tells it to do - so it tries to change the ACL of the file so that it gives
owner@ rw, group@ r and everyone@ r permissions. That call to vfs_fchmod does
not occur with Samba 4.19.9 and earlier?
>
> A wild guess is that this change of behaviour is due to the code for
implementing smb3 unix extensions somehow (even though we have that disabled
with ?smb3 unix extensions = no? in smb.conf).
>
> Ah well. I?ll keep on debugging this...
>
> - Peter
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba