[RFC] Making D-Bus suitable for being run early during boot

[Lennart Poettering]

On Fri, 09.07.10 12:04, David Zeuthen (zeuthen at gmail.com) wrote:

> 
> Hi,
> 
> On Fri, Jul 9, 2010 at 11:28 AM, Colin Walters <walters at verbum.org> wrote:
> >> b) The system bus should become an abstract namespace socket by
> >>   default. This would require changing of the spec.
> >
> > This is a pretty incompatible change.
> 
> I think client libraries are supposed to honor the
> DBUS_SYSTEM_BUS_ADDRESS environment variable. So presumably we could
> just ensure that it's always set. But that won't work anyway, because
> security-sensitive setuid software (such as pkexec(1)) of course
> clears that environment variable to avoid getting fooled (presumably
> the hostile caller could arrange for a system bus with fake services
> that is running at an address of his choice). So yeah, the change is
> incompatible. And then there's the other problem with abstract
> namespaces I mentioned in the other mail.

I am not aware of any issues that would apply here. 

Abstract namespace sockets are a fine choice for priviliged code that
runs so early at boot that no user could invade its namespace.

> Lennart, why exactly do want or need the socket to be abstract? Also
> note that abstract socket is a Linux-only thing so mandating it in the
> spec kinda makes D-Bus a Linux-only thing. I'm not sure we want that.

Well, the spec could say "look for an abstract namespace socket foo
first, if it applies to your OS. Then fallback back to a fs socket bar".

Here's another idea: if you are really concerned about taking away the
/var socket we could just support both: when dbus starts it would listen
only on the abstract socket, and then, when /var becomes available we
bind to the fs socket as well.

The reason why I want the abstract socket is that it works regardless
whether any fs is writable, and hence can be bound from the moment on
userspace exists. The only other place I could think of that is writable
this early is /dev/shm, but overloading that dir this way doesn't look
like an awesome solution to me.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.