Subject: Re: /var/cron -> /etc/cron
To: None <firstname.lastname@example.org>
From: Miles Nordin <carton@Ivy.NET>
Date: 04/05/1999 17:39:05
In a previous post I had trouble understanding why the community needs to
worry about the arguably naive and certainly unusual choice to mount /
read-only. Posts from
(changing ownership of devices at runtime)
(example ro / scenario)
helped me understand why it makes sense to support this as long-term
simplicity and flexibility.
Given this context, I should point out that read-only root does not need
to _break_ /etc/cron--it merely needs to make crontabs immutable. This is
likelyactually _desireable_ on a site that wants the passwd DB, aliases
DB, rc.conf, _all configuration_, to be unwriteable, perhaps even
protected by the Security Level. I think it demonstrates that crontabs are
more like configuration than like spool files or at jobs.
A positive way to embrace ro root seems, to me:
o device ownerships in /dev change at runtime
o syslog (formerly) creates /dev/log at startup
o not updating mtimes in /dev breaks idle time in finger and w
o users cannot update their crontabs or use chfn, passwd, u.s.w.
An ro root system should be useful and simple to set up, but it cannot,
need not, and _should_ not behave identically to an rw root system. Such
behaviour is complex to achieve _and_ probably undesireable.
Previously I explained my opinion that, while crontabs have both
/etc and /var characteristics, the /etc characteristics predominate; also
that read-only roots, hand-waving security concerns, u.s.w., are small
compared to putting files where they philosophically ``belong.''
Idealistic and impractical as it may seem, this effort to solve classes of
problems we haven't imagined yet has bought us the greatest benefit in the
past: a system that both is easy to mess with, and communicates a
positive style of thought to the people who try to understand it. I'll
avoid belabouring this--obviously it's not an argument for /etc/cron or
/var/cron so much as a method for deciding.
One proposal that i don't find compelling is putting crontabs in $HOME;
the file permission and amd issue alone should kill it, but i think the
wrapper function of crontab is rather virtuous as well:
o It does stuff: syntax/permission checking, signals to crond, collect
files for faster scanning
o Because we got in the habit of using vipw, implementing passwd DB
was far more transparent. crontab provides useful data abstraction.
it could evolve to pre-parse crontabs or let cron scan 3000 tabs
o a job that runs constantly like lfscleanerd is more elegant than a
once-per-interval scan. updates happen immediately, and there
is no bursty resource consumption of a long-running batch job.
for this to work well, users should not be able to create or delete
crontabs without using the wrapper--therefore they must go in a directory
users can't write.
besides, $HOME is site-specific, and crontabs are host-specific. You do
not want your job started on all 100 machines at once, or none at all.
You probably (should) want it run once.
> Sorry for being longwinded (yet again),
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700