[nfsv4] Re: back to AA

[Chris Inacio <[e-mail]>]

>> 
>> I would like to add an Authentication/Authorization topic.  To scope down what I would like to discuss here: I need to read RFC2203 first.  Just from browsing the table of contents for 2203, I’m not sure this helps me understand what are *the protocol needs* with how a file system backend stores/maps the network identity of the client.
> I don't know if this will help save you some time, but here is my
> recollection of how RPCSEC_GSS/Kerberized NFS works...
> - The client translates a user identity into a Kerberos principal (a
> string like "[e-mail]")
>   (This is usually a trivial mapping of username and default REALM.)
>  --> The client uses the user's TGT to acquire a session ticket from the KDC.
> - The GSSAPI layer wraps this session ticket up in a blob they call a token.
> - This "token" is sent to the server via a Null RPC by RPCSEC_GSS layer.
>  --> There is a back and forth between client and server, using Null RPCs
>       in the RPCSEC_GSS layer that, if successful, authenticates the Kerberos
>       prinicipal name on the server and creates a shorthand for the
> Kerberos principal.
>       (Translation from Kerberos principal is whatever the server
> chooses to do.
>         For POSIX like systems, it typically strips off the @REALM
> and then looks the
>         name up in the password/group databases to create POSIX
> credentials for the user,
>         which are associated with the shorthand mentioned above.)
> --> Then the client uses the shorthand (authenticated via encryption
> using the session key
>      from the Kerberos session ticket) to identify the "user" to the
> server. That's what RPCSEC_GSS
>      is doing for non-NULL RPCs.
> (Hopefully this is close. It has been a long time since I coded this stuff.)
> 

This is really helpful, thanks.  (Is this in nfsuserd in FreeBSD?  Pulling up the code - you apparently wrote it in 2009.  ;).  I’m happy because it’s basically a single file of 909 lines.)

Ganesha must do this differently, right?  Doesn’t it run in user space?  Does it have a separate DB for this mapping?  The example I can find is Ganesha running on top of Ceph – and it doesn’t seem to be particularly running in user space. (https://github.com/nfs-ganesha/nfs-ganesha/wiki/Kerberos-setup-for-NFS-Ganesha-in-Ceph) I am making a lot of guesses on Ganesha operation I’ve realized.

> In theory, other mechanisms than Kerberos can be created for GSSAPI/RPCSEC_GSS,
> but there has not been much done. (Long ago there was an RFC and some code for
> a public key system, but no one adopted it.)
> 
> It sounds like Tigran et al might be thinking of a new mechanism,
> although I haven't looked
> at what he has written up yet,
> 

Right now there is more the statement of what might go in such a draft than the text itself.  I would really like to understand how someone who manages a hybrid multi cloud instance for data storage deals with AA.  It must be complicated.  The SCIM WG (https://datatracker.ietf.org/wg/scim/) is developing cross-domain identity management.  I have no idea if it would help at all, but if that’s a the right tool for a problem we (eventually) face it’s available.  (Although from what little I know of it, I would rather use ONC RPC than RPCs built on top of HTTP, but maybe I’m just old.)

>> Please *do not* think I’m trying to standardize how that works (that is a server implementation choice) but what needs to be on the wire to enable servers do that _however they chose to do it._
> Reading through enough of the POSIX ACLs some of the large
> differences between NFSv3 and NFSv4 become clear.
> I'm not sure if this sounds silly, but on-the-wire it is basically a
> string (owner/owner_group defines it as "user@domain",
> where the domain was never well defined. (Right now, most just handle
> one "domain". I don't think there is even a well
> defined way of checking "same string". By this I mean, does the DNS
> case insensitive and/or puny encoded rules apply?)
> 

Good points to consider if there is an extension to think about how to update AA.

> (For authentication, it is still a string, but with something that assures the
> server that it is legit.
> 
> rick