[patch] direct service connections
walters at verbum.org
Sat Nov 6 10:27:27 PST 2004
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.
More information about the dbus