333d04678d
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 |
||
---|---|---|
.. | ||
atrun | ||
convert.pl | ||
cron | ||
ftpd | ||
gdm | ||
imap | ||
kde | ||
login | ||
Makefile | ||
other | ||
passwd | ||
pop3 | ||
README | ||
rsh | ||
sshd | ||
su | ||
system | ||
telnetd | ||
xdm |
This directory contains configuration files for the Pluggable Authentication Modules (PAM) library. Each file details the module chain for a single service, and must be named after that service. If no configuration file is found for a particular service, the /etc/pam.d/other is used instead. If that file does not exist, /etc/pam.conf is searched for entries matching the specified service or, failing that, the "other" service. See the pam(8) manual page for an explanation of the workings of the PAM library and descriptions of the various files and modules. Below is a summary of the format for the pam.conf and /etc/pam.d/* files. Configuration lines take the following form: module-type control-flag module-path arguments Comments are introduced with a hash mark ('#'). Blank lines and lines consisting entirely of comments are ignored. The meanings of the different fields are as follows: module-type: auth: prompt for a password to authenticate that the user is who they say they are, and set any credentials. account: non-authentication based authorization, based on time, resources, etc. session: housekeeping before and/or after login. password: update authentication tokens. control-flag: How libpam handles success or failure of the module. required: success is required; on failure all remaining modules are run, but the request will be denied. requisite: success is required, and on failure no remaining modules are run. sufficient: success is sufficient, and if no previous required module failed, no remaining modules are run. binding: success is sufficient; on failure all remaining modules are run, but the request will be denied. optional: ignored unless the other modules return PAM_IGNORE. arguments: Module-specific options, plus some generic ones: debug: syslog debug info. no_warn: return no warning messages to the application. Remove this to feed back to the user the reason(s) they are being rejected. use_first_pass: try authentication using password from the preceding auth module. try_first_pass: first try authentication using password from the preceding auth module, and if that fails prompt for a new password. use_mapped_pass: convert cleartext password to a crypto key. expose_account: allow printing more info about the user when prompting. Note that having a "sufficient" module as the last entry for a particular service and module type may result in surprising behaviour. To get the intended semantics, add a "required" entry listing the pam_deny module at the end of the chain. $FreeBSD$