Re: Documentation regarding NFSv4

Russell L. Carter wrote:
>On 2020-09-18 16:28, Rick Macklem wrote:
> > Oh, and I forgot to mention name<->id# mapping.
> > If using AUTH_SYS (not kerberos), then you have the
> > choice of running "nfsuserd" or setting these two sysctls to 1.
> > vfs.nfs.enable_uidtostring=1
> > vfs.nfsd.enable_stringtouid=1
> > --> This makes the server just handle id#s (uid, gid) as numbers in
> >         a string. (This is the default for Linux these days although
it was
> > '       frowned upon in the early days.)
> >
> > Running nfsuserd maps uid, gid numbers to/from names using the
> > password and group databases. This must be used for Kerberos mounts.
> >
> > Without the above properly configured, you'll see lots of files owned
> > by "nobody" on the client mounts.
>
>Those sysctls are interesting.  I wasn't aware of them and so I run
>nfsuserd.  What do they do, practically speaking?  My understanding,
>likely wrong, is that nfsuserd should allow different uid/gid
>server->client mappings, possibly different for different clients.
Well, in theory, yes.
In practice, that never really happened.
When NFSv4 was being designed, putting uid/gid numbers in file attributes
was felt to be too POSIX centric, so in file attributes, they are defined
as a string of the form "user_at_domain" or "group_at_domain".
What never happened was a good definition of what "domain" was supposed
to be or how clients/servers would handle multiple domains.
--> So, only one "domain" normally works and it is usually the same
      as the domain part of the machine's hostname.

Linux got tired of doing the number->string and string->number
mapping (awkward for NFS mounted root file systems, since the mapping
daemon is not running right away), so they switched to just doing
"uid" and "gid" (ie. the numbers in strings).
--> By setting the sysctls (both for the server), you run Linux compatible
       and don't need to run the nfsuserd (unless you use the -manage-gids
       option on it).

These days Linux is the de-facto standard (unless you are using Windows).

>However I still had to sync uid/gids across machines even though they
>are all running nfsuserd.  Didn't disable nfsuserd because... system
>is working... DFWI.
Well, user authentication is a different story...
- For Kerberos, the kerberos user principal is translated to POSIX
  credentials by the gssd daemon and you don't need a consistent
  uid, gid space, but do need to run nfsuserd, since the "uid" and "gid"
  strings don't work.
- Otherwise, you are using AUTH_SYS, which means the RPC authenticator
  has a uid and gid list in it and the credentials are derived from that.
  (If you run "nfsuserd -manage-gids", then the uid is used to acquire
   a list of gids on the server from its group database. Otherwise, the
   list of gids in the RPC authenticator is used.)
  --> You need a uniform uid space (and uniform gid space unless you
         are using "nfsuserd -manage-gids".

Confusing, yes.

rick
 
Anyway, naked FreeBSD-stable nfsv4 is rock solid in a clamped down
arena with a variety of FreeBSD and Debian clients.  Kudos.

Thanks,
Russell

 > rick
 >
 > ________________________________________
 > From: Rick Macklem <rmacklem_at_uoguelph.ca>


_______________________________________________
freebsd-current_at_freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"