Page MenuHomeFreeBSD

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

Authored by rmacklem on Oct 19 2024, 8:31 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 3, 4:07 PM
Unknown Object (File)
Sat, Nov 16, 3:20 PM
Unknown Object (File)
Wed, Nov 13, 3:40 AM
Unknown Object (File)
Nov 7 2024, 3:08 PM
Unknown Object (File)
Nov 7 2024, 8:48 AM
Unknown Object (File)
Nov 2 2024, 3:17 AM
Unknown Object (File)
Oct 30 2024, 3:14 AM
Unknown Object (File)
Oct 26 2024, 9:58 AM
Subscribers

Details

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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

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.

This revision is now accepted and ready to land.Oct 21 2024, 3:52 PM

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

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.