[nfsv4] Re: Feedback on user ID for any bis work

["Mkrtchyan, Tigran" <[e-mail]>]

Hi Chris,

----- Original Message -----
> From: "Chris Inacio" <[e-mail]>
> To: "Chuck Lever III" <[e-mail]>
> Cc: "Tigran Mkrtchyan" <[e-mail]>, "NFSv4" <[e-mail]>
> Sent: Thursday, 5 September, 2024 18:12:45
> Subject: Re: [nfsv4] Feedback on user ID for any bis work

> Tigran,
> 
> This is great; really what I had in mind.  I had been trying to puzzle through
> this myself.  For me (and its because I don’t know the mechanics of NFS well
> enough, at this point) the thing I am mentally tied up in is some form of
> “mapping” from these external identities to file system UIDs.  LDAP provides a
> binding of directory authentication to a local UID which makes basic
> permissions easy to do on POSIX file systems.  Would another service /
> configuration mechanism be necessary to provide these remote ID to local UID
> mappings?  This gets a lot easier for filesystems that actually provide

OpenID-Connect tokens provide both identity information and access rights.
For other protocols, namely for HTTP, we can use LDAP to map users to a local
account and do permission validation based on Unix permissions. Alternatively,
we can trust the identity provider and use an access token, like
'storage.read:/path/to/dir' and by-pass local permission validations.

The latter one is more complex for NFS, so my main focus (for now) is user mapping.


> workable ACLs, as far as I can tell.  Then you have the ability to at least
> provide a binding (even if it isn’t cryptographically strong at rest) of a
> permission on the server filesystem to the remote identity service.
> 
> Correct me if I have any of this wrong, please.  When I last worked at a file
> systems company, I did TCP/IP interface and acceleration.  So the real
> mechanics and nuances of NFS aren’t totally clear to me.
> 
> Side note: I was trying to understand how this works by reading the NFSv42 XDR.
> That does not seem to really include anything with regards to authentication
> in there.  There is an include of “auth.h” which seems a little less than
> ideally portable to me.

I think the best place to start is RPCSEC_GSS https://datatracker.ietf.org/doc/html/rfc2203.

Best regards,
   Tigran.


> 
> Chris
> 
> 
>> On Sep 5, 2024, at 9:48 AM, Chuck Lever III <[e-mail]> wrote:
>> 
>> Warning: External Sender - do not click links or open attachments unless you
>> recognize the sender and know the content is safe.
>> 
>> 
>>> On Aug 29, 2024, at 11:02 AM, Mkrtchyan, Tigran <[e-mail]>
>>> wrote:
>>> 
>>> 
>>> 
>>> Hi Chick,
>>> 
>>> The current state is available at:
>>> 
>>> https://github.com/kofemann/rpc-sec-oidc/blob/main/draft-tigran-nfsv4-rpcsecoidc.md
>>> 
>>> It is still quite raw, but indeed, if people comment, this will give me some
>>> guidelines and momentum.
>> 
>> Thanks for posting, Tigran! I will make some time in the next
>> couple of weeks to study the draft.
>> 
>> 
>> --
> > Chuck Lever