Fix the NFS server's handling of exported mapped credentials with cr_ngroups == 0

[rmacklem]

Summary

There has been a documented case in the exports(5) man
page forever, which specifies that the -maproot or -mapall
may have a single user entry, followed by a ':'.
This case is defined as specifying no groups (aka cr_ngroups == 0).

This patch fixes the NFS server so that it handles this case correctly.

After MFC'ng this patch to stable/13 and stable/14, I propose that
this unusual case be deprecated and no longer allowed in FreeBSD15.
At that point, this patch can be reverted.

Test Plan

Tested with an /etc/exports line that looks like:
/example -maproot=rmacklem:
and confirmed via a kernel printf that cr_ngroups == 0
for the maproot credentials.

Then I tested access to a file over NFS that looked like:
-rw-r----- 2 root nogroup 1021 Oct. 7 08:41 zzzz.c
to see that access was not allowed for "root" on the client.

[brooks]

This seems fine. Is this fix the result of a bug report or just something you noticed? If the latter I wonder if just fixing the documentation would be simpler if the feature never worked.

[rmacklem]

In D47204#1076708, @brooks wrote:

This seems fine. Is this fix the result of a bug report or just something you noticed? If the latter I wonder if just fixing the documentation would be simpler if the feature never worked.

Unfortunately "never worked" is actually "might allow an access when it was
not supposed to" (basically if the random junk in cr_groups[0] happens to
match the file's gid), which is not likely to get noticed.

olce@ reported this as part of a series of patches he has that ensure that
cr_ngroups == 0 never happens. However, changing the man page for
extant releases seems like a POLA violation to me, so I have proposed
doing this fix for stable/13 and stable/14, then disabling the case for
main/current (done by olce@'s patches).

[brooks]

In D47204#1076734, @rmacklem wrote:

In D47204#1076708, @brooks wrote:

This seems fine. Is this fix the result of a bug report or just something you noticed? If the latter I wonder if just fixing the documentation would be simpler if the feature never worked.

Unfortunately "never worked" is actually "might allow an access when it was
not supposed to" (basically if the random junk in cr_groups[0] happens to
match the file's gid), which is not likely to get noticed.

Makes sense to me.