State of vfs_nfs4acl_xattr.
Maciej Bonin
mbonin at phys.ethz.ch
Tue Jul 6 12:59:06 UTC 2021
Dear Samba developers,
I've recently tried to get vfs_nfs4acl_xattr to work for re-exporting of
an nfs4 mount from a linux server.
As far as I can tell, this is simply not possible at the moment. Am I
correct in that belief ?
I've adjusted all the default parameters to make it somewhat funtional,
to the values below:
==CUT
nfs4acl_xattr:encoding = nfs
nfs4acl_xattr:nfs4_id_numeric = yes
nfs4acl_xattr:xattr_name = system.nfs4_acl
nfs4acl_xattr:validate_mode = no
nfs4acl_xattr:default acl style = posix
nfs4acl_xattr:version = 40
==CUT
However, this seems to work only on directory ACLs, and, for files,
neither the NFS4 ACLS, nor the "default" doubly-synthetic acls generated
from standard POSIX permissions, work at all.
For an end user, this seems like you can create and write files, but
never edit or even read/download them again.
Everything I've tried leads to NT_STATUS_ACCESS_DENIED. The sd struct in
debug logs seems to look ok, even when the access fails, but I'm not
that familiar with NT ACLs to be able to fully verify that. And most
certainly not familiar enough with samba internals and source to
understand why the checks (presumably performed against samba's
internalt NT/nfs4 acl representation created even when not using the vfs
module) fail. Please see the below output:
==CUT
[2021/07/05 11:36:11.156400, 10, pid=730056, effective(13117, 2320),
real(13117, 0)] ../../source3/smbd/open.c:210(smbd_check_access_rights)
smbd_check_access_rights: acl for testfile.img is:
[2021/07/05 11:36:11.156413, 1, pid=730056, effective(13117, 2320),
real(13117, 0), class=rpc_parse]
../../librpc/ndr/ndr.c:429(ndr_print_debug)
sd: struct security_descriptor
revision : SECURITY_DESCRIPTOR_REVISION_1 (1)
type : 0x8004 (32772)
0: SEC_DESC_OWNER_DEFAULTED
0: SEC_DESC_GROUP_DEFAULTED
1: SEC_DESC_DACL_PRESENT
0: SEC_DESC_DACL_DEFAULTED
0: SEC_DESC_SACL_PRESENT
0: SEC_DESC_SACL_DEFAULTED
0: SEC_DESC_DACL_TRUSTED
0: SEC_DESC_SERVER_SECURITY
0: SEC_DESC_DACL_AUTO_INHERIT_REQ
0: SEC_DESC_SACL_AUTO_INHERIT_REQ
0: SEC_DESC_DACL_AUTO_INHERITED
0: SEC_DESC_SACL_AUTO_INHERITED
0: SEC_DESC_DACL_PROTECTED
0: SEC_DESC_SACL_PROTECTED
0: SEC_DESC_RM_CONTROL_VALID
1: SEC_DESC_SELF_RELATIVE
owner_sid : *
owner_sid : S-1-22-1-13117
group_sid : *
group_sid : S-1-22-2-2320
sacl : NULL
dacl : *
dacl: struct security_acl
revision : SECURITY_ACL_REVISION_NT4
(2)
size : 0x004c (76)
num_aces : 0x00000003 (3)
aces: ARRAY(3)
aces: struct security_ace
type :
SEC_ACE_TYPE_ACCESS_ALLOWED (0)
flags : 0x00 (0)
0: SEC_ACE_FLAG_OBJECT_INHERIT
0: SEC_ACE_FLAG_CONTAINER_INHERIT
0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
0: SEC_ACE_FLAG_INHERIT_ONLY
0: SEC_ACE_FLAG_INHERITED_ACE
0x00: SEC_ACE_FLAG_VALID_INHERIT (0)
0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
0: SEC_ACE_FLAG_FAILED_ACCESS
size : 0x0018 (24)
access_mask : 0x00160187
(1442183)
object : union
security_ace_object_ctr(case 0)
trustee : S-1-22-1-13117
aces: struct security_ace
type :
SEC_ACE_TYPE_ACCESS_ALLOWED (0)
flags : 0x00 (0)
0: SEC_ACE_FLAG_OBJECT_INHERIT
0: SEC_ACE_FLAG_CONTAINER_INHERIT
0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
0: SEC_ACE_FLAG_INHERIT_ONLY
0: SEC_ACE_FLAG_INHERITED_ACE
0x00: SEC_ACE_FLAG_VALID_INHERIT (0)
0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
0: SEC_ACE_FLAG_FAILED_ACCESS
size : 0x0018 (24)
access_mask : 0x00120081
(1179777)
object : union
security_ace_object_ctr(case 0)
trustee : S-1-22-2-2320
aces: struct security_ace
type :
SEC_ACE_TYPE_ACCESS_ALLOWED (0)
flags : 0x00 (0)
0: SEC_ACE_FLAG_OBJECT_INHERIT
0: SEC_ACE_FLAG_CONTAINER_INHERIT
0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
0: SEC_ACE_FLAG_INHERIT_ONLY
0: SEC_ACE_FLAG_INHERITED_ACE
0x00: SEC_ACE_FLAG_VALID_INHERIT (0)
0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
0: SEC_ACE_FLAG_FAILED_ACCESS
size : 0x0014 (20)
access_mask : 0x00120081
(1179777)
object : union
security_ace_object_ctr(case 0)
trustee : S-1-1-0
[2021/07/05 11:36:11.156781, 10, pid=730056, effective(13117, 2320),
real(13117, 0)] ../../source3/smbd/open.c:1320(open_file)
open_file: smbd_check_access_rights on file testfile.img returned
NT_STATUS_ACCESS_DENIED
==CUT
This file has the following nfs4 xattr permissions:
==CUT
nfs4_getfacl /home/isg/testfile.img
A::OWNER@:rwatTcCy
A::GROUP@:rtcy
A::EVERYONE@:rtcy
==CUT
and the following POSIX permissions directly in the filesystem:
==CUT
getfacl /export/censored/isg/testfile.img
getfacl: Removing leading '/' from absolute path names
# file: export/censored/isg/testfile.img
# owner: username_for_uid_13117
# group: name_for_gid_2320
user::rw-
group::r--
other::r--
==CUT
Please note that the failure occurs in very much the same way whether
the file actually has extended ACLs set or not.
While I don't expect this to work at the moment, and have reverted to
re-exporting nfs mounts purely using nfs3 and letting it follow POSIX
extended ACLs, my question is: Will vfs_nfs4acl_xattr ever be in a state
where it's possible to use the synthetic xattr from nfs4 mounts and
respect (or even edit/set) the extended ACLs, or is this rather very low
priority for you ?
Additionally, could you explain what the original rationale for the vfs
module was at all ? I don't understand which implementation the options
described in the manual page (and, even more confusingly, the defaults)
are supposed to support. A native NTFS+ filesystem exported from a
POSIX-compliant host ? There seems to be another module for zfs, which
has yet another incompatible implementation available natively, but that
doesn't seem to be related to vfs_nfs4acl_xattr.
Kind regards
--
Maciej Bonin <mbonin at phys.ethz.ch> support:
IT Services Group, HPT H 8 voice:
Department of Physics, ETH Zurich
CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/
More information about the samba-technical
mailing list