tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: /sbin/reboot and secmodel

At 07:26 AM 3/19/2008 +1100, Daniel Carosone wrote:
On Tue, Mar 18, 2008 at 08:35:58AM -0400, Terry Moore wrote:
> It seems to me that moving things to init makes the system
> not-extensible-without-a-kernel-recompile.


Sorry, I suppose you're confused that I included "init" in the kernel-recompile. I guess I should have said "not-extensible-without-source-access-to-kernel-and-key-processes-like-init". Or something else altogether more understandable.

init(8) is certainly part of the base system. Using set-uid, etc., it's possible for a sysadmin to add (within fairly broad limits) a number of new facilities to his/her platform without making any changes to init(8) [or, more generally, to the base system]. This has, I think, obvious benefits:

1) no need to worry about merging patches
2) modularity
3) no need to worry about odd side effects within init(8) [this last may be a critical point for mission-critical high-volume applications]

In any event, I might have misunderstood, but I don't see how one can add additional behavior to init(8) [pulling in the functionality of reboot(8), in this example] without something like:

a) having the person making the extension change source code in init(8),
b) adding a scripting language to init(8) [so that the extension is written in the scripting language], or c) teaching init(8) to support dynamic-DLL loading and some kind of ABI (so the extension is provided as a DLLs).

Approach (a) has the disadvantages cited above.

Both (b) and (c) solve the extensibility problem, but I would not think this extensibility would make sense in init(8).

If I've misunderstood your "huh?" completely, then....  sorry!


Home | Main Index | Thread Index | Old Index