[nfsv4] Re: Feedback on user ID for any bis work

[Mark Liam Brown <[e-mail]>]

On Fri, Aug 16, 2024 at 6:26 PM Chuck Lever III
<chuck.lever=[e-mail]> wrote:
>
>
>
> > On Aug 16, 2024, at 11:39 AM, Chris Inacio <[e-mail]> wrote:
> >
> > Dave, All,
> >
> > INDIVIDUAL CONTRIBUTOR HAT ON - NOT CHAIR
> >
> > We need this super brief conversation in one of the interim meetings about how user identity is communicated across NFSv4, and there are 2 options, UID/GID ‘integer's and then loosely defined ‘string’.  So I’ve been digging into this and I would say, most definitely, do NOT remove the string.  So what I can see so far, is that UID/GID numbers are used when auth ‘sys’ is the selected mechanism, where current the string is used when auth is tied to GSS-API.  As far as I can tell, the kerberos principal name should be the string in the field.  I certainly don’t yet have a full understanding about how everything is connected together.  (Just sending the principal is nice and everything, but you want to be able to verify it, and HOLY RAT HOLE ROBIN is that confusing in practice.)
> >
> > So, the thing I’m trying to make sense of, how hard would it be to support TLS identities (X.509 certs really) instead of Kerberos.
>
> A perhaps subtle distinction here:
>
> The current RPC-with-TLS protocol uses x.509 explicitly only for authenticating
> network peers (ie, hosts). RFC 9289 even says "not for user authentication". So
> I think the term "TLS" here is probably misplaced.
>
> You instead want to invent a new RPC security flavor or flavors that authenticates
> users (or, dare I say it, to extend GSSAPI to handle this for us) via an x.509
> certificate, or OAuth, or such like. Nothing to do with transport layer security,
> which doesn't know from users.
>
>
> > That also opens a fairly different control domain.  Kerberos is well suited to local enterprise control.  You can do that with X.509, but really, my anecdotal experience says, X.509 certs for enterprise are too heavy a lift, but they’re the answer when you want a more global identity.  That raises the question of target users of NFS protocol.  And if we’re (or maybe that’s just me doing it?) opening a wound there – then maybe we want to be able to support authentication and authorization that is more cloud compatible, which is potentially more than X.509.
> >
> > These are just thoughts and feedback on some discussions.
> >
> > Chris
> >
> >
> > P.S.
> >
> > The complexity of auth is BONKERS!!!  So to kind of dig into this I have a freenas server running with ZFS as the backing store.  It’s the FreeBSD variant 13.0 stream.  I then deployed an LDAP and Kerberos solution (freeipa on Fedora) to have that running on an RPi4.  (This is all in my house, by the way.) For clients, I have a _real_ menagerie of machines: Mac OS 14.6, RPi Raspbian, FreeBSD, and Win 11.  For fun, that means NFS versions running are:  Mac OS 14.0 - NFSv4.0, Raspbian/Linux NFSv4.2, FreeBSD 13.x - NFSv4.1, Win 11 - NFSv3.  I can get most of the unixen to at least get a Kerberos user principal TGT.  Machine-to-machine, host principals are still a bit of a challenge.  The Windows machine seemingly would rather piss in my Cheerios than do what I want.  (What engineer where convinced their UI people to be able to give error messages as ‘1450 resource unavailable’ and then you need to type `net helpmsg 1450` to get an actual error message, which is completely useless anyway?  That person is either my hero or the devil.) And while Windows doesn’t want to cooperate at all, the unixen management of authentication identities is its own entire disjoint universe!  ‘SSSD' on Linux, ‘nfsuserd' on FreeBSD, and I haven’t even tried to cross that bridge on Mac.  So I’m still trying to get this collection of stuff to attempt to do full kerberos/gss-api negotiation on a mount.
> >
> >
> > Maybe this is why people run with auth sys!
>
> No "maybe" about it, this /is/ why people stick with auth_sys.

But even auth_sys must support user@name on Windows, because Windows
has no concept of uid/gid. The Windows NFS41 driver just sends the
Windows domain\user converted to user@domain to the NFS server.

Mark
-- 
IT Infrastructure Consultant
Windows, Linux