[patch] direct service connections

[Colin Walters]

On Sat, 2004-11-06 at 11:46 -0500, Havoc Pennington wrote:

> How do we start that and manage its lifecycle? Maybe it's slaved to the
> sessionwide bus?

I was thinking the app would fork/exec it, and its lifecycle would be
tied to the main session bus.

> If you define that each session has a bus for the whole session, and
> then child buses for each machine involved in the session, then you need
> some way to identify which machines there are.
> 
> One possibility is come up with a way to have a guid per machine.

Hmm.  Not sure how that would work in general.  If you have a
predictable guid, then an attacker could create a file with that name
in /tmp and stop your session-local bus from starting.

> Another possibility is something like:
>  - session bus creates a guid for the session
>  - the session-machine bus listens on a socket whose name can be 
>    created from the guid
>  - you can thus ensure there's only one session-machine bus per session-
>    machine pair by checking existence of the socket from the app's 
>    filesystem namespace
>  - the session-machine bus connects to the session bus and exits
>    when the session bus does
> However, in this possibility I don't know who fork/execs the 
> session-machine bus. It sort of has to be the app, but that introduces
> certain annoying issues (and more logic than desired in libdbus)

Yeah, I don't see an alternative to doing it in libdbus.

In non-thin-client setups of course, 
DBUS_BUS_SESSION_LOCAL == DBUS_BUS_SESSION.