[nfsv4] Re: back to AA

[David Noveck <[e-mail]>]

On Friday, September 6, 2024, 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.)
>
> 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-ganesh
> a/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.)


Your age doesn't matter.  Neither does mine.   What does  matter is that
NFSv4 is defined to use ONC RPC and it would be a massive undertaking to
try switch that. We would need a major justification to justify this
enormous amount of work including a way to replace the functionality of rpc
over rdma in an http framwork.

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


I'm assuming you are not proposing updating anti-aircraft.  Seriously,
updating authentication is a big job and I don't see any need to update
authorization beyond the world Rick has proposed for draft POSIX ACLs.
Trying to update.both of these together would be a big mistake.

>
> > (For authentication, it is still a string, but with something that
> assures the
> > server that it is legit.
> >
> > rick
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>