[Samba] Strange permissions/ZFS ACL issue on 4.20-4.22

[Peter Eriksson]

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