'RELENG_7_0_0_RELEASE'.

This commit was manufactured to restore the state of the 7.0-RELEASE image.

by unavailable accounts, e.g., those locked, expired, not allowed in at
the moment by nologin(5), or whatever, depending on cron's pam.conf(5).
This applies to personal crontabs only, /etc/crontab is unaffected.

In other words, now the account management policy will apply to
commands scheduled by users via crontab(1) so that a user can no
longer use cron(8) to set up a delayed backdoor and run commands
during periods when the admin doesn't want him to.

The PAM check is done just before running a command, not when loading
a crontab, because accounts can get locked, expired, and re-enabled
any time with no changes to their crontabs.  E.g., imagine that you
provide a system with payed access, or better a cluster of such
systems with centralized account management via PAM.  When a user
pays for some days of access, you set his expire field respectively.
If the account expires before its owner pays more, its crontab
commands won't run until the next payment is made.  Then it'll be
enough to set the expire field in future for the commands to run
again.  And so on.

Document this change in the cron(8) manpage, which includes adding
a FILES section and touching the document date.

X-Security: should benefit as users have access to cron(8) by default

mailbox protocols.  Add pam_unix to the `account' function class, too,
for imap and pop3 to actually implement this policy.

so that the change history stays easily readable as the number
of PAM-aware services grows.

instead of an authentication function.  There are a design reason
and a practical reason for that.  First, the module belongs in
account management because it checks availability of the account
and does no authentication.  Second, there are existing and potential
PAM consumers that skip PAM authentication for good or for bad.
E.g., sshd(8) just prefers internal routines for public key auth;
OTOH, cron(8) and atrun(8) do implicit authentication when running
a job on behalf of its owner, so their inability to use PAM auth
is fundamental, but they can benefit from PAM account management.

Document this change in the manpage.

Modify /etc/pam.d files accordingly, so that pam_nologin.so is listed
under the "account" function class.

Bump __FreeBSD_version (mostly for ports, as this change should be
invisible to C code outside pam_nologin.)

PR:		bin/112574
Approved by:	des, re

method of executing commands remotely.  There are no rexec clients in
the FreeBSD tree, and the client function rexec(3) is present only in
libcompat.  It has been documented as "obsolete" since 4.3BSD, and its
use has been discouraged in the man page for over 10 years.

this wasn't there already...  it makes much more sense this way.

MFC after:	2 weeks

OK'ed by:	core

any fake value.