D-Bus User Bus

Havoc Pennington hp at pobox.com
Wed May 19 12:30:19 PDT 2010


On Wed, May 19, 2010 at 2:18 PM, Thiago Macieira <thiago at kde.org> wrote:
> Another way to look at this is to have only a user bus, but introduce a
> session or domain concept inside it. Connections in one domain can only see
> connections in that domain, plus the global domain. Access to a domain is
> granted by knowing the domain's "secret" at connection time (like an ID at
> handshake or by connecting to a special Unix socket whose name is random and
> is saved in an environment variable).

This is almost equivalent to sticking the display name at the end of
bus names in terms of effect, but more transparent to apps...

The bus name flags stuff is extensible so it might be:

 * the bus is a per-(user,machine) bus
 * inside the bus, mark most bus names as per-session with a session
ID associated with them
 * associate each connection to the bus with a session ID
 * names are per-session by default unless an ACROSS_ALL_SESSIONS flag
is set when taking name ownership
 * filter out names from other sessions when listing names, etc.

if you don't bother to actually _prevent_ cross-session access (it's
all the same user after all - don't need to be secure from yourself)
then it's easier.

It still has the issue though that fundamentally the same homedir can
be on two different machines at once :-P
so per-machine user bus just does not fix the "multiple sessions problem"

I think launching per-user services on the system bus would be easier
to implement fwiw but who knows what complexities arise with either
one in practice.


More information about the dbus mailing list