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

is <19990405131252.A23002@jocelyn.rhein.de> 
 (changing ownership of devices at runtime)
tls <19990404215631.A7990@rek.tjls.com> 
 (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:
 attend to:
   o device ownerships in /dev change at runtime
   o syslog (formerly) creates /dev/log at startup
 ignore:
   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
   efficiently.
 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),

*blush*

-- 
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700