Re: Moving rc.d scripts to base.tgz

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

On Apr 15, 2011, at 2:26 17AM, Thor Lancelot Simon wrote:

> On Fri, Apr 15, 2011 at 07:12:42AM +0200, Michael van Elst wrote:
>> On Thu, Apr 14, 2011 at 06:54:14PM -0400, Thor Lancelot Simon wrote:
>> 
>>> If I'm concerned about the possibility of configuring a system daemon
>>> in such a dangerous way, I can remove it -- or elsewise pin down its
>>> configuration.
>> 
>> Like the system daemon /bin/sh or is just inetd evil ?
> 
> Thank you for strategically cutting and pasting my text in order to
> remove any semblance of meaning.
> 
> Have you actually ever tried to build a Unix system with a real,
> verifiable TCB?  I have.  What I'm suggesting are things that I know
> would make it easier, because I've actually tried it about 10 different
> ways over the past 15 years, and I have some recollection of what was
> a real pain in the butt and what wasn't, really, all that hard to work
> around.
> 
> As I pointed out, I have, in fact, built Unix systems with no /bin/sh.
> I find it preferable to build systems a little less weird than that if
> I can.

I confess I'm amazed that it was even possible to get a running system
that way.  I'm sure it took strange and wondrous "adaptations"...

On a more serious note: while overall I like Thor's proposal, I think
that the criteria he proposes are not quite correct.  The real problem,
I think, is a 3-way split between "this was on the distribution", "this
is a site/enterprise/product customization", and "this is host-specific".
Under that split, /etc/rc.d would be in the first category and rc.conf
and/or the ifconfig_XX files would be in the third category.

The question is how best to implement this.  For directories, overlay
mounts (with whiteout) could work.  Thus, at boot time, /etc/rc would
mount /etc.site on top of /etc and /etc/site.local on top of that.  (Left
unsolved in my proposal how a site could say "believe only the rc.conf.d
or /etc/rc.d in /etc.site and don't permit it to be overlaid".)

It's worse for files like /etc/inetd.conf, where you might want some of
the changes in the new version but still have to merge in your own
site-specific changes.  I don't have a great answer for that.

This is all part of a larger problem I've muttered about in the past:
how can we make upgrades easy when there are site-specific changes?
One reason I use my own wrapper script to do installs on my -current
boxes is the need to 'chmod 0 /usr/bin/lp*" because I use cups.  NetBSD
is far better than Linux, of course, since it does have /usr/local/bin
and /usr/pkg/bin, but it's still harder than I'd like to override
standard files.

Bottom line: moving rc.d somewhere, as Thor proposes, is a good idea, but
there's a deeper, more general problem that we should think about first.

                --Steve Bellovin, https://www.cs.columbia.edu/~smb