IRC meeting

[Rob Ubuntu Linux]

On Nov 27, 2007 3:10 AM, Shawn Rutledge <shawn.t.rutledge at gmail.com> wrote:
> On Nov 26, 2007 4:31 PM, Scott James Remnant <scott at netsplit.com> wrote:
> > On Mon, 2007-11-26 at 13:40 -0700, Shawn Rutledge wrote:
> >
> > > On Nov 26, 2007 2:01 AM, Scott James Remnant <scott at netsplit.com> wrote:
> > All init needs to do is spawn processes, and reap them when they die;
> > with some handling for determining when it needs to do the former and
> > working out what to do about the latter.
>
> Well at first glance I was inclined to think that when upstart aims to
> replace crond and atd, those might be good examples of functionality
> that could be plugins.  Then again, the whole point is that events
> trigger processes to be launched, and the state of the system clock
> can be just another kind of event, so making upstart have cron
> functionality is pretty much aligned with its usual behavior.

Given the case made elsewhere, for small simple code, I'm wondering
what  you really gain by bringing cron & atd into 1 process.
Currently there's a choice of cron packages to which may suit some
deployments better than others.  Making a monolithic program in 1
package, will mean choosing the right behaviour, which then may become
a limititation, should say the machine be part of some cluster, with
distributed batch processing (or the unfeasible complication of
implementing all possible behaviours in a critical system daemon).

At least Ubuntu /sbin/init is dymamically linked, rather than
traditional static linking, so assuming the libc is the same that is
shared with later processes, then at least code isn't being duplicated
in system RAM for no good reason.  Whilst many design choices from
UNIX may have been made due to limitations of 16 bit address space, on
a swapping architecture, rather than demand paging; having seperate
processes mean the kernel automatically multi-tasks these components
on a multi-CPU system.  The drawback may be that upgrading libc is
more fragile, without a statically linked toolchain available as a
last resort.

Keeping init(8) simple, as Scott suggests above looks to me like a
good design decision.

> I suppose in the extreme case, anytime any process wishes to run
> another process as root, init could do it (via an IPC request of
> course); that way there is just one place where escalation of
> privileges is handled.  But I'm sure you can think of some arguments
> against that (it sure isn't very traditional).

You look like you'll be interested in Policy Kit at Freedesktop.org
which is specifically targetted at fine grained privilege escalation.
The problem is that "running another process as root" is doable by
setuid bit, but security wonks would like to enable minimum capability
required, to follow principal of least privilege.

Moving the access control mechanism into user space, rather than
kernel, could easily expose race conditions; so it looks like quite a
tough project to me, which small mistakes could jeopardise gains made
in other areas.

> > Can save snapshots of the system status ... And why is this useful?  If
> > you want to snapshot your system, hibernate it.

Hibernate / resume, makes lots of assumptions about state of hardware,
is not usable where system will be rebooted into different OS, or not
resumed on next boot, so I presume the "snapshot feature" is actually
more akin to session idea in desktops which attempt to restart
programs where they left off.

> Maybe it would be nice to define runlevels by example rather than by
> editing code.  E.g. start the services that you want to be running,
> kill everything you don't, and then generate a runlevel definition
> based on the current system state.  But that can be done by an
> external program easily enough.  Not sure if it's even good idea...
> just an idea that's all.

Superficially that sounds attractive, but having thought about it, I
think that wouldn't work too well in practice.  The reason is that
during lifetime of system, you tend to add new daemons, possibly also
change the ones you run.  With this model, the admin would have to
re-create the system state to redefine the snapshot of the system
state, which would be an error prone process.

Daemons that are in packages, with knowledge of their dependencies,
for example "nameservice", can be added without reducing availability
of system.  They also may run, when lower level daemons required even
during system maintenance, would be added or altered, so that way
you're not forcing the admin to keep track of very many server
processes.

As Upstart is specified to understand dependancies and dynamically
decide start up order, of these processes, it would be a huge step
back, to impose that knowledge on the admin, and it would be beyond
most end users.