> -----Original Message-----
> From: Nehring, Shane R [LAS] [mailto:snehring@iastate.edu]
> Sent: Tuesday, June 21, 2022 3:07 PM
> To: ffilzlnx@mindspring.com; support@lists.nfs-ganesha.org
> Subject: Re: [NFS-Ganesha-Support] Re: Proxy-v4 access denied
>
> 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.

Start with is idmapd running on all nodes? Do you have the same idmapd.conf on all systems? Also, are your user ids the same on all systems? You can look at GETATTR in the network trace and see how the IDs are going across. You can add IDMAPPER=Full_Debug to your LOG { COMPONENTS {} } config.

> 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.

The underlying filesystem will do some of the permission checking, and it's permission checking may override Ganesha's.

> 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.

I'll have to look at the PROXY_V4 code to see if it actually does ACLs. It might not.

Frank

> 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@mindspring.com; support@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
> > > >
> > > >
> >
> >

_______________________________________________
Support mailing list -- support@lists.nfs-ganesha.org
To unsubscribe send an email to support-leave@lists.nfs-ganesha.org