which init thoughtfully revoke()'s when starting a getty on ttyv0. This
Cron's popen() was passing these fd's through to cron children (ie:
sendmail, *not* normal cron jobs). The side effects were usually
not noticed, but it tripped up postfix which did a sanity check to see
that stdin/out/err were open, and got EBADF even thought the fd's were
in use. I seem to recall sendmail itself has hacks to work around
this problem, it had a checkfd012() function, possibly for this same
problem. (Postfix has a workaround too now though..)
This is a hack, not a fix. It's probably best to check and perhaps
close/reopen() /dev/console if needed each time around the event loop.
It would probably be useful to actually see any error messages from cron.
Prevent cron from going crazy if the time steps. For example, if you
have a system with hundreds of users and lots of different crontabs
and your time steps back an hour, the old cron would then attempt to
run an hours worth of cron jobs in a few seconds.
libraries so that `ld -f' in can create correct dependencies for
yet-to-be-built libraries.
Get the default BINDIR correctly (by including ../Makefile.inc recursively.
Override the default it it is wrong.
Don't override defaults when the defaults are correct.
Use getpwnam before getpwuid since two users with same uids can exists
(affects new login classes code only)
The same fixes as in inetd: by default run `system crontab things' with
daemon login class now, not restrict them to user class breaking
compatibility with old way (so-called nobody limits problem)
Implement user[:group][/login-class] syntax in system crontab
for more flexible control (the same as in inetd)
I suspect it was because the child exec code's parent was doing the
initial lookups, then forking, then doing other things (possibly trashing
the static data in the getpw*() buffer), then attempting to dereference
*pwd and *lc. Also, no error checking appeared to be done - I've allowed
it to fall back to the old "become user" code on critical failure rather than
risk running a user's cron jobs as root.
Use setusercontext() rather than setuid()/setgid()/setlogin()/initgroups()
which is all handled. Login environment is NOT set by this call as crontab
provides its own means of doing so.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
used by OpenBSD. (Quite frankly, I think it's perfectly reasonable to
use snprintf to copy strings, given that the semantics for strncpy()
are utterly idiotic and there is no POSIX sstrncpy().)
While I'm at it, incorporate some of OpenBSD's bugfixes to cron.
NOT for 2.2
