User bus conclusion

[Lennart Poettering]

On Wed, 10.11.10 16:13, Thiago Macieira (thiago at kde.org) wrote:

> > We found only two really existing problematic use cases:
> > 
> > - gdm managing multiple screens, and running a greeter session for each
> >   of them. In the short tun to make this work we'd just continue to use
> >   dbus-daemon --session which won't go away. In the long run we should
> >   probably use dynamic uid allocation, since we definitely want
> >   isolation between the greeter sessions, so that should one manage to
> >   get a shell it should be impossible to gdb the other.
> 
> An alternative is to make the login tool stop using the session bus. kdm 
> doesn't, even though it's a bit of effort to ensure it doesn't.

There's no way around this. If you care about a11y, you need audio and
all kinds of other user agents. If you need audio you need pulseaudio,
and bluetooth. And so on and so on. You will end up with something that
very much resembles a normal session if you do things properly. And gdm
does things properly.

I know that some folks believe that running a full session for the
greeter is crazy, but in real life, there isn't really a way around it.

> > - Internet cafe/kiosk setups, where one user id serves multiple
> >   workstations. The solution for this is kinda similar.
> 
> You mean a thin client run from a remote server with the same UID?

Yes.

> Anyway, the cases I can think of -- and this is just the initial thinking 
> without trying to find corner cases -- boil down to trying to access a service 
> that shows a UI when executing a non-local simultaneous login (ssh
> -X).

Well, if the user overrides $DISPLAY, then that's fine. This will
continue to work. In that case the app he runs will show its dialogs on
a different screen then the rest of the session uses, but all the other
user services will be used from the actual machine the app is running
on, which is what makes sense I believe.

Basically, what happens is that each user "supersession" will have one
default $DISPLAY which is $XDG_RUNTIME_DIR/x11-socket, it will have one
default dbus bus, which is $XDG_RUNTIME_DIR/dbus/dbus_user_bus. It will
have one default PA server as $XDG_RUNTIME_DIR/pulseaudio/native. It
will have one dconfd server as $XDG_RUNTIME_DIR/dconfd/whatever. And so
on and so on. If a user now decides to mix and match things and wants to
deviate from that he is welcome to, and can set the $DISPLAY
accordingly. However, it's his own problem and he has to deal with the
fallout. We will by default keep as much as possible on the machine that
is running the process, and as much as possible running as the user id
that initiated the supersession, but if the user decides to mix and
match user ids, or displays/audio servers/dconf servers/busses, then it
he can do that manually, and has to deal with the problems this creates.

> For example, my workstation in the office keeps my KDE session running all the 
> time. Sometimes, I need to get a password from the KWallet, so I'll ssh -X in 
> and run kwalletmanager. That currently starts a local D-Bus session and 
> kwalletd, which in turn shows the password dialog.

local to which side? You are not sharing the dbus session across the
network, are you? So nothing really changes here. THis will continue to work.

> With the user bus proposal, there would be no local D-Bus session. Instead, 
> the launched kwalletmanager application would be talking to the kwalletd 
> running on my local display. And that would then proceed to show the password 
> dialog in the wrong screen.

I am a bit confused what you mean by "local".

> > I guess, if we continue to honour $DBUS_SESSION_BUS_ADDRESS, however
> > just not set it anymore in modern sessions (gnome, kde) then this and
> > similar use cases should not be much of a headache.
> 
> I didn't get this part. Can you clarify what you meant?

Well, if sombody does dbus_bus_get(DBUS_BUS_SESSION) what he gets is a
connection to $DBUS_SESSION_BUS_ADDRESS if that is set, and to if it
isn't to $XDG_RUNTIME_DIR/dbus/dbus_user_bus. GNOME would then not set
this env var anymore and we would benefit from clear semantics and full
parallelization. However, KDE could continue to set it, and would
continue with the old semantics.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.