[nfsv4] Re: back to AA

[David Noveck <[e-mail]>]

On Sunday, September 8, 2024, David Noveck <[e-mail]> wrote:

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