[RFC] Fixing the machine id

[Lennart Poettering]

On Fri, 04.03.11 17:45, Marcel Holtmann (marcel at holtmann.org) wrote:

> 
> Hi Lennart,
> 
> > With this in place there's very little left which stops us from spawning
> > D-Bus already during early boot: the system bus activation needs to be
> > moved to /usr. Or alternatively we just give up officialyl on seperate
> > /usr, in which case we don't need to. I'd be very much in favour of
> > that, but you know the politics. The bigger problem is of course the
> > system bus socket, which is in /var/run/dbus/. But we probably could
> > move that to an abstract socket or one in /dev/.dbus, relatively
> > easily.
> 
> using the abstract socket is bad for security since you have no
> permission checks anymore. And essentially anybody could start owning
> that socket. You do not really want that.

Well, the system bus socket is accessible by everybody anyway, and
authentication is based on SCM_CREDENTIALS mostly anyway. Note that on
Linux the session bus (i.e. the bus that is private to the user)
actaully does use a (random) abstract namespace socket.

I think D-Bus is one of the very few cases where fixed name abstract
namespace sockets are safe: after all we do this all to be able to start
it as early as possible, and that means at a time where unprivileged
code doesn't run yet. Also, D-Bus is not restartable. FInally, in a
socket based environment it could even be restartable, but the socket
could never be taken away from systemd and dbus.

> Also the system socket address is pretty much hardcoded. At least when I
> looked through that a few weeks ago. And then changing the address
> becomes quickly big trouble. Only advantage with systemd would be that
> you can easily set an environment variable for every process. So it
> might work out for you. In general it is a big mess.

Well, other options thinkable are:

a) bind mount the socket into /var/run as soon as that is available.

b) teach dbus to listen on two sockets, and not fail if it cannot create
one. Then, send it a sighup or so to retry to establish all sockets.

c) Do the passthru magic ubuntu is currently doing, which i find kinda
messy, but might be an option after all: during early boot already mount
/var/run and /var/lock, but into a fake /var. Then, after mounting the
real /var into a temporary mount point, bind mount both into them, and
finally atomically move the temporary mount point to the real place,
thus always guaranteeing that /var/run and /var/lock are available all
the time.

d) introduce /dev/.systemd/run and /dev/.systemd/lock, and make /var/run
and /var/lock just a bind mount alias of that. Or, do it even smarter:
when booting up, make /dev/.systemd/{run,lock} symlinks to
/var/{run,lock}, then mount the tmpfs on that so that the symlinks are
not visible anymore. Finally, when /var is up, just atomically move the
mount from /dev/.systemd/{run,lock} to /var/{run,lock}, revealing the
symlinks again. That way everybody in need of /var/run during early boot
can access it via /dev/.systemd/run. And it will stay accesible through
that all the time.

I kinda like the idea of d).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.