This enables additional searching the manual by sysctl variable.
This syntax is standardized in style.mdoc(5).

Reported by:	bapt
MFC after:	3 days

On most other platforms observed, including OpenBSD, NetBSD, and Linux,
these system calls have long since been converted to only touching the
supplementary groups of the process.  This poses both portability and
security concerns in porting software to and from FreeBSD, as this
subtle difference is a landmine waiting to happen.  Bugs have been
discovered even in FreeBSD-local sources, since this behavior is
somewhat unintuitive (see, e.g., fix 48fd05999b0f for chroot(8)).

Now that the egid is tracked outside of cr_groups in our ucred, convert
the syscalls to deal with only supplementary groups.  Some remaining
stragglers in base that had baked in assumptions about these syscalls
are fixed in the process to avoid heartburn in conversion.

For relnotes: application developers should audit their use of both
setgroups(2) and getgroups(2) for signs that they had assumed the
previous FreeBSD behavior of using the first element for the egid.  Any
calls to setgroups() to clear groups that used a single array of the
now or soon-to-be egid can be converted to setgroups(0, NULL) calls to
clear the supplementary groups entirely on all FreeBSD versions.

Co-authored-by:	olce (but bugs are likely mine)
Relnotes:	yes (see last paragraph)
Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D51648

We previously would not have setgroups() at all, but now we would drop
our supplementary groups every time.  This broke chroot -n, probably
among other things.  We need tests here, but lets unbreak things first.

A future change may try to setgroups(2) when -u is specified in addition
to -G, so predicate the call on gidlist and don't populate that without
a grouplist.

PR:		288751
Fixes:	48fd05999b0f ("chroot: don't clobber the egid [...]")

gid_t and uid_t are unsigned types, so the values are always >= 0.

usr.sbin/chroot/chroot.c: In function 'resolve_group':
usr.sbin/chroot/chroot.c:68:55: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits]
   68 |         if (errno == 0 && *endp == '\0' && (gid_t)gid >= 0 && gid <= GID_MAX)
      |                                                       ^~
usr.sbin/chroot/chroot.c: In function 'resolve_user':
usr.sbin/chroot/chroot.c:87:55: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits]
   87 |         if (errno == 0 && *endp == '\0' && (uid_t)uid >= 0 && uid <= UID_MAX)
      |                                                       ^~

Reported by:	GCC
Fixes:		91eb4d2ba4de ("chroot: slightly cleanup")

Highlights:
 - Pull resolve_user() and resolve_group() out to make the main flow
    a bit easier to read
 - Fix some edge-cases in user/group resolution: you can have fully
    numeric usernames, and they may or may not live within the valid
    ID range.  Switch to just trying to resolve every specified
    group/user as a name, first, with a fallback to converting it to a
    numeric type and trying to resolve it as an ID.
 - Constify locals in main() that don't need to be mutable, re-sort

Reviewed by:	emaste, olce
Differential Revision:	https://reviews.freebsd.org/D51509

When the security.bsd.unprivileged_chroot sysctl is set, chroot(2) can
be used by unprivileged users as long as the PROC_NO_NEW_PRIVS_CTL
process control is set.

chroot(8) has a -n command line flag to set this process control.
Add an explicit error for EPERM from chroot(2) if the -n flag is
necessary, but not present.

Before:
  $ chroot / /bin/sh
  chroot: /: Operation not permitted

After:
  $ chroot / /bin/sh
  chroot: unprivileged use requires -n

Reviewed by:	kevans
Sponsored by:	The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51687

Reviewed by:    kevans, ziaee
MFC after:      3 days
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D51511

There are two problems here, really:

1.) If -G is specified, the egid of the runner will get clobbered by
    the first supplemental group
2.) If both -G and -g are specified, the first supplemental group will
    get clobbered by the -g group

Ideally our users shouldn't have to understand the quirks of our
setgroups(2) and the manpage doesn't describe the group list as needing
to contain the egid, so populate the egid slot as necessary.

I note that this code seems to have already been marginally aware of the
historical behavior because it was allocating NGROUPS_MAX + 1, but this
is an artifact of a later conversion to doing dynamic allocations
instead of pushing NGROUPS_MAX arrays on the stack -- the original code
did in-fact only have an NGROUPS_MAX-sized array, and the layout was
still incorrect.

MFC after:	3 days
Reviewed by:	olce
Differential Revision:	https://reviews.freebsd.org/D51508

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

We've ifdef'd out the copyright strings for some time now. Go ahead and
remove the ifdefs. Plus whatever other detritis was left over from other
recent removals. These copyright strings are present in the comments and
are largely from CSRG's attempt at adding their copyright to every
binary file (which modern interpretations of the license doesn't
require).

Sponsored by:		Netflix