[nfsv4] Re: Interim meeting agenda topics

[Rick Macklem <[e-mail]>]

On Fri, Sep 6, 2024 at 1:05 PM Chris Inacio <[e-mail]> wrote:
>
> All,
>
> What would the agenda topics for the (yet to be scheduled) interim meeting be?
>
> What is left to be resolved / is controversial on the POSIX_ACL draft?
>
> 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.)

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,

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

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

rick

>
> Dave what issues (not precisely drafts) are highest on your list of things to get resolved for us to make progress.
>
>
> Chris
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]