5:07 p.m.
What's the best way to debug the idmapper stuff? I changed the mode of the exported
directory to 0775 which is allowing me to
access the mount now. Which would expected if the uids are wrong.
With this change I'm able to get more responses from the server, and looking at those
in the network capture it certainly looks
like the correct uids and gids are being sent from the upstream nfs server at least as far
as owner uid and group are concerned.
And once past this hurdle of accessing the mount root, permissions seem to be enforced
according to the underlying file system
acls.
I wonder if I managed to compile this without acl support, as nfs4_getfacl fails with
'Operation to request attribute not
supported' on the mount as root.
Shane
On Tue, 2022-06-21 at 13:19 -0700, Frank Filz wrote:
I'm not sure what PROXY_V4 does with ACLs, though it seems like
it should support them. If so, it supports NFSv4 ACLs. The
proxied server would have to offer NFSv4 ACLs. If the proxied server is Linux, it will
translate POSIX ACLs to NFSv4 ACLs. If
the proxied server is Ganesha, it would do the same for FSALs that support POSIX ACLs
(not FSAL_VFS yet).
The call to fsal_check_access_no_acl() in the log indicates Ganesha is doing mode bit
permission checking. The log indicates
the permissions are 0770, so the other permissions are being used. That strongly suggests
idmapping is failing somewhere,
check out the various things I pointed to in the previous e-mail.
Frank
> -----Original Message-----
> From: Nehring, Shane R [LAS] [mailto:snehring@iastate.edu]
> Sent: Tuesday, June 21, 2022 12:41 PM
> To: ffilzlnx(a)mindspring.com; support(a)lists.nfs-ganesha.org
> Subject: Re: [NFS-Ganesha-Support] Re: Proxy-v4 access denied
>
> Thank you Frank, the additional acl debug logging might've given me a
direction
> to go:
>
> [svc_7] nfs_access_op :NFS4 ACL :DEBUG :Requested
> ACCESS=READ,LOOKUP,MODIFY,EXTEND,DELETE,-
> [svc_7] nfs_access_op :NFS4 ACL :DEBUG :access_mask = mode(rwx)
> ACL(list_dir,add_file,execute,add_subdirectory,delete_child)
> [svc_7] fsal_check_access_no_acl :NFS4 ACL :F_DBG :file Mode=0770, file
> uid=0, file gid= 0, user uid=423245, user gid= 101,
> access_type=0X7000000
> [svc_7] fsal_check_access_no_acl :NFS4 ACL :F_DBG :Mask=0X0, Access
> Type=0X7000000 Allowed=0X0 Denied=0X7000000 DENIED [svc_7]
> nfs_access_op :NFS4 ACL :DEBUG :Supported
> ACCESS=READ,LOOKUP,MODIFY,EXTEND,DELETE,-
> [svc_7] nfs_access_op :NFS4 ACL :DEBUG :Granted ACCESS=-,-,-,-,-,-
>
> Does ganesha interpret posix acls for the purpose of determining access? I've
> got these trees setup with perms delegated primarily with posix acls on the
> underlying filesystem instead of traditional owner/group perms.
>
> In the meantime I'll look at the captures and getting them filtered and
> investigate id mapping.
>
> Shane
>
> On Tue, 2022-06-21 at 11:53 -0700, Frank Filz wrote:
> > You config looks like it should work, however, do you gave ID Mapper
> > configured identical on all three hosts involved (client, Ganesha
> > server, proxied server)? Could you share you network traces (both between
> client and Ganesha and between Ganesha and the proxied server)? Could you
> share the debug log? You could add NFS4_ACL to log the permission checking
> which might help.
> >
> > On the idmapper stuff, you need to determine if the owner/group
> > attributes coming from the server are in the form "user@domain" or
> > "1234". You may need to set NFS4 { Allow_Numeric_Owners = true; }
in
> > your config if the owner/group attributes are numeric. The parameter
> > Only_Numeric_Owners will cause Ganesha to issue owners in the form
"1234"
> instead of "user@domain" for client side GETATTR and proxy side SETATTR
(and
> OPEN/CREATE). There are kernel NFS parameters that control this also for client
> and I believe the server.
> >
> > I'm going to bet that idmapping issues are the cause here. I hope the
> > above gives you enough to go on to fix the issue if that's the case.
> >
> > Frank
> >
> >