[systemd-devel] Questions regarding dbus started via systemd --user

[Dimitri John Ledkov]

On 8 January 2015 at 17:24, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> On 08/01/15 16:03, Dimitri John Ledkov wrote:
>> There is upstart --user spawned per session, and everything is under
>> it. The sessions' logind cgroups are parent of all processes within a
>> session, and there are sub cgroups as needed for contained
>> jobs/processes. Thus for three graphical sessions, one has three
>> upstarts running, three dbus (with different bus ids), etc.
>>
>> Thus my expectation would be to have a systemd (dbus, etc...) --user
>> per-session/per-seat, rather than per-uid.
>
> This is a conversation about the distinction between a per-(uid,machine)
> bus (the "user bus") and a per-login-session bus (the "session bus").
> We've had this discussion several times in the past, although perhaps
> not involving you personally. I'll follow-up with some "further reading"
> links about session bus vs. user bus, but freedesktop.org's mail
> archives are a bit of a labyrinth so I wanted to get this sent off
> before going looking for the right historical threads.
>
> The "session bus" philosophy is how the D-Bus session bus was designed
> to work around a decade ago. It's a consistent conceptual model (...
> ish), but it breaks down as soon as you want to do something like leave
> a headless Rygel service running after you log out, or interact with
> your X11 session's D-Bus services from a ssh or getty login.
>
> It also means you can't use D-Bus names as single-instance mutexes to
> avoid "last write wins, earlier writes are lost" (or worse!) data
> corruption in the home directory, because it allows more than one D-Bus
> session to share a home directory, even in the absence of NFS or
> whatever. This was meant to be one of the uses of D-Bus name ownership
> semantics, so it's a pity that it has never worked in the general case.
>
> Finally, there is no canonical list of the situations that the session
> bus does and doesn't support, so whenever someone raises a bug or
> feature request about one of the corner cases, nobody knows whether it's
> a bug or a feature request or just wrong. Typical corner cases include:
>

True, hence we only enabled user session management with upstart on
the graphical logins.

However, we also included facilities to join/part a given user session.
Thus one can join a given upstart session id, and control it, query
it's environment and move into that environment.
(Not automated, but there are qa scripts that do that for validation)


> * I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
>   and log in at the getty. How do I communicate with X11 session things
>   over D-Bus, perhaps to disconnect from Telepathy without losing
>   messages?
> * The same, but I ssh in from another machine instead. Same question?

On Ubuntu at the moment this looks in practice something like this:
find UPSTART_SESSION_ID of your tty7 session, export that variable in
your getty shell, then use initctl list-env ("systemctl") to list
environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use
that to communicate with dbus.

In essence it's no different from today world where your getty login
doesn't have your tty7 DBUS_SESSION_BUS_ADDRESS.

> * I'm in an X11 session on aardvark, and I open a terminal
>   emulator and do "ssh -X badger", then run an app on badger.
>   For session bus purposes, is it part of my login session on aardvark,
>   a new login session on badger, an existing login session on badger,
>   or what? Why?

Not enabled, but would be new ssh-session on badger.

> * The same, but I shared my home directory via NFS.

Not tested by me. But e.g. dbus is spawned by upstart without a pid or
anything like that, or uses XDG_RUNTIME_DIR which is unique per
session, and thus not hitting NFS.

> * The same, but I shared my home directory via NFS, and configured
>   dbus-daemon to be available over TCP (yes, this is apparently
>   something that is meant to work).

The second session will fail to start, cause well you can't bind to
same TCP port twice.
This is a distro bug though, as the graphical-distro has it's user
jobs setup to by default to be in good order.

> * I run "su". In the su shell, I run an app that wants to connect to
>   the D-Bus session bus. Does it connect to my existing session bus,
>   a new session bus for root, some existing session bus for root,
>   or what? Why?

As currently, and in ubuntu case, a new dbus session bus is
autolaunched - standard dbus behaviour. The reason being is that "su"
sessions do not get user-init/logind-session(?!) and thus don't
inherit those things nor launch new ones.

> * I run "su -". Is it the same as "su"? Why/why not?
>

Not sure, don't have an answer here. In upstart we did limit
user-sessions to be for non-root/non-system users that can login.

> In response to concerns like those, various people have promoted the
> "user bus" as a replacement for the session bus, or occasionally as a
> second parallel bus. Where the session bus is per (uid,login session)
> and the system bus is per-machine, the user bus is per (uid,machine).
>

Right, that would be flexible to address "background user serverish
things" vs "unique user in-my-face things".

> 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?!

> I think having a session bus *and* a parallel user bus, which some
> people have advocated in the past, is worse than having only the session
> bus and should be avoided, because message order is not preserved
> between distinct buses, and application authors shouldn't be required to
> deal with IPC that happens in a non-deterministic order.
>
> As far as I understand it, systemd's kdbus userland is intended to
> support a system bus (the equivalent of dbus-daemon --system) and a user
> bus, but there is no intention to support traditional session buses,
> because the people writing systemd's D-Bus-related code are among those
> who think the user bus is the way forward.
>

I don't have a deep opinion on this, cause I am not competent enough
to comment on it. 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).

-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.