[nfsv4] Re: numeric vs, name@domain representations of users and groups

[David Noveck <[e-mail]>]

On Tue, Jun 2, 2026 at 2:09 PM Pali Rohár <[e-mail]>
wrote:

> On Tuesday 02 June 2026 13:52:15 David Noveck wrote:
> > On Sun, May 31, 2026 at 10:47 PM Thomas Haynes <[e-mail]> wrote:
> >
> > > On Sun, May 31, 2026 at 10:04:59AM -0800, David Noveck wrote:
> > > > Previous specifications such as RFC5661 and RFC8881 had little
> useful to
> > > > say about this matter, leading to the text making this depend  on
> use of
> > > > AUTH_SYS in the text regarding this in security-14.
> > > >
> > > > I have just discovered that RFC7530 takes pretty much the same
> approach
> > > and
> > > > intend to refer to RFC7530 in a forthcoming security-15 which will be
> > > > submitted within the next week together with rfc8881bis-08.
> > > >
> > > > IIRC, someone previously mentioned the existence of an implementation
> > > > that used name@domain together with AUTH_SYS, which RFC7530 says
> *SHOULD
> > > > NOT* be done.  Even apart from the whole "valid reasons" imbroglio,
> > >
> > > Where does it say that? I see that it says you SHOULD NOT use numeric
> > > ids with AUTH_KRB5.
> > >
> >
> > But In  section 5.9 of rfc7530, it does say, "For any other security
> > mechanism, the server SHOULD accept
> > such numeric values."  I guess that makes it OK to accept both and I
> > mistaken in assuming that
> > the numeric form was recommended.  Nevertheless, the one of the
> treatment is
> > miles/liggt-years away from the whole "you-might-*subvert-*the-switch-to
> > -name@domain arrative in other
> > docments.
>
> Section 5.9 of RFC8881 says:
>
> "To avoid this mechanism being used to subvert user and group
> translation, so that a client might pass all of the owners and groups in
> numeric form, a server SHOULD return an NFS4ERR_BADOWNER error when
> there is a valid translation for the user or owner designated in this
> way. In that case, the client must use the appropriate name@domain
> string and not the special form for compatibility."
>
> IMHO, this email discussion just shows that this topic is not clear what
> server or client MUST do or SHOULD do and what SHOULD NOT.
>

Right.  Two important sources of this lack of clarity:

   -  My misreading of RFC7530, which Tom pointed out.
   - The fact that different specfications say different things and that
   the obvious quasi-solution, to treat v4.0 and v4.1 as having different
   requirements results in a maintenance nightmare.

I'm going to make a proposal addressing current confusions in security-15.
There appears to be no reasonable chance of it being in
*draft-ietf-nfsv4-security-00* in any reasonable time frame.  I am hoping
to have participation from all sides on tis and hope to have a discussion
at the nextt interim meeting.

I'm not anticipating this will achieve consensus but it will take a
coherent position on the issues so that we have a basis to argue what
should be in the security document so that we have a consensus that can
appear when the security document is ready for publication, assuming that
Gorry finds a way to resolve the adoption blockage.