[systemd-devel] Questions regarding dbus started via systemd --user
Simon McVittie
simon.mcvittie at collabora.co.uk
Thu Jan 8 11:32:36 PST 2015
On 08/01/15 17:42, Dimitri John Ledkov wrote:
> On 8 January 2015 at 17:24, Simon McVittie
> <simon.mcvittie at collabora.co.uk> wrote:
>> I personally think having only the user bus (and having
>> (G_|DBUS_)BUS_TYPE_SESSION connect to it) is the best long-term setup,
>> because it's easy to understand and does not try to impose isolation
>> between sessions that are not actually a privilege boundary (same uid,
>> can ptrace each other, etc.).
>>
>> Having only the session bus (as we do in e.g. Debian 8) is the next best
>> thing; it's at least an internally consistent model, even if it does
>> have a bunch of stupid corner cases.
>
> only the session bus, but per-session though?! If i have two graphical
> sessions on tty1 & tty2 they will have different
> DBUS_SESSION_BUS_ADDRESS, right?!
The difference between those two models is exactly: is that last
sentence true or not?
In the "only the session bus" world: yes, they have distinct session buses.
In the "only the user bus" world: no, DBUS_SESSION_BUS_ADDRESS points to
the user bus, probably unix:path=/run/user/1234/bus (where 1234 is your
uid) or some analogous kdbus thing.
Typical general-purpose distributions are currently (as of e.g. Debian
8) living in the "only the session bus" world. However, it seems that
systemd's kdbus userland is set to have "only the user bus", unless
someone changes its developers' minds; and as far as I know, every
previous attempt to make "dbus-daemon --session" into a systemd --user
service has also followed the "only the user bus" model.
> But I'm sure bits of graphical apps stack would then
> need to be adjusted to be seats or at least active_seat aware in
> system/user bus configuration. (e.g. pop a window up on
> active_seat/session, rather than the one you were
> dbus/socket-activated on).
Yes, if the graphical environment supports more than one simultaneous
graphical session per uid per machine at all. Another example of
something that would have to change if that situation was to be
supported on a user bus is that the X11 parts of gnome-settings-daemon
(mainly the Xsettings manager) would have to have one instance per X11
display, with different D-Bus names.
As usual, there is a trade-off here. The advocates of a user bus believe
that the benefits of a user bus outweigh the costs (or to put it another
way, that the benefits of multiple session buses do not outweigh their
costs). The advocates of a session bus per $DISPLAY believe the opposite.
S
More information about the dbus
mailing list