cvs commit: src/etc/pam.d Makefile cron src/usr.sbin/cron/cron Makefile cron.8 cron.h database.c do_command.c src/usr.sbin/cron/lib Makefile entry.c

Yar Tikhiy yar at comp.chem.msu.su
Mon Jun 18 10:04:17 UTC 2007


[Re-replying to the list]

On Mon, Jun 18, 2007 at 04:29:22PM +0800, LI Xin wrote:
> Hi,
> 
> Yar Tikhiy wrote:
> > yar         2007-06-17 17:25:53 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     etc/pam.d            Makefile 
> >     usr.sbin/cron/cron   Makefile cron.8 cron.h database.c 
> >                          do_command.c 
> >     usr.sbin/cron/lib    Makefile entry.c 
> >   Added files:
> >     etc/pam.d            cron 
> >   Log:
> >   Add PAM support to cron(8).  Now cron(8) will skip commands scheduled
> >   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.
> 
> This will silently break a lot of ports, for instance mail/mailman,
> which creates nologin(5) users with crontab entry.  Can we for now
> (because we are near a new release) try not disabling nologin(5) users,
> and discuss a better solution?

I guess that the ports create nologin(8) users, that is, users with
their shell set to /usr/sbin/nologin.  Such users also should have
a single asterisk in their password hash field to denote a system
account.  Nevertheless, that doesn't prevent such users' crontab
commands from running after my change.

With the default PAM configuration, user's crontab commands won't
run if at least one of the following is true:

- the user account is expired (but expired password isn't a reason
  not to run commands)
- the user account is administratively locked out using "pw lock"
  (this isn't the same as a single asterisk in the password hash field)
- the admin has temporarily disabled user logins by creating a nologin(5)
  file, usually /var/run/nologin.

Therefore, the ports shouldn't be broken by my change and their
crontab commands will happily run most of time, except for system
maintenance periods when /var/run/nologin exists, which can be a
desired effect.

> A possible alternative is to make a pam_ftpusers(8) alike PAM module
> which is marked as "sufficient" and explicitly pass /var/cron/allow
> users (especially ports) to override the policy.

If /var/cron/allow exists, then it's the users listed in it who are
subject to the PAM check in cron(8) as the rest of users just cannot
use cron(8).  Consequently, there is no reason for the new module.
Note that by default we don't install /var/cron/allow or /var/cron/deny,
we just allow any user to use cron(8).

-- 
Yar


More information about the cvs-src mailing list