[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Moving rc.d scripts to base.tgz
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
>> 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
> 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
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
Main Index |
Thread Index |