[nfsv4] Re: back to AA

[Rick Macklem <[e-mail]>]

On Fri, Sep 6, 2024 at 6:41 PM Chris Inacio <[e-mail]> wrote:
>
> >>
> >> 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.)
It is the part that does the owner/owner_group names when "uid #s in
the string" is not enabled
(which is always the case for Kerberized mounts). Basically the
FreeBSD equivalent to idmapd
on Linux distros.

The other piece is the gssd, which does the GSSAPI calls for RPCSEC_GSS.
(I wasn't the author of this one, although I did write a more
primitive one long ago.)

And then the big piece is the Kerberos libraries (which include the
GSSAPI calls,
if you are using open source, such as MIT or Heimdal).
Adding a mechanism to the GSSAPI code in MIT's Kerberos distro is what
I thought Tigran
was planning?
--> Somehow there needs to be a relationship between "user name",
"authentication principal"
     and "the name in owner/owner_group". Right now, I think most
implementations (maybe all?)
     make these three the same string.

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