User bus conclusion

[Thiago Macieira]

Em Quarta-feira, 10 de Novembro de 2010, às 14:06:24, Lennart Poettering 
escreveu:
> On Wed, 10.11.10 08:53, Thiago Macieira (thiago at kde.org) wrote:
> > Moreover, there are many use-cases that get broken by the user bus
> > proposal. The question is whether they are valid today...
> 
> Many? Can you elaborate?

Yes. All of them related to having different $DISPLAYs.

> 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.

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

Dynamic UID allocation sounds a lot better here.

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).

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.

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.

The same thing applies to many other KDE services, like the download progress 
windows (shown out-of-process by kuiserver or by plasma-desktop). The process 
is launched by klauncher, which inherits one specific $DISPLAY variable and 
will then show in the wrong display. 

This also applies to any process launched via kdeinit/klauncher, which is 
about everything launched programmatically (i.e., without the user typing a 
command in a shell). All of the launched applications would show up in the 
wrong display -- if I click a link, the browser is launched by klauncher.

For that matter, any KUniqueApplication would simply break, though it might 
not be a bad thing. Right now, they are unique per session therefore per 
display. With this change, they would be unique per user, which is the upside. 
However, the way that it is architected right now, if you simply typed 
"dolphin" or "konsole" in an ssh or ssh -X shell while these are already 
running, the application would immediately exit with success -- and the new 
window would be showing in the workstation in the office.

And also there are many places in the KDE D-Bus API where XWindow handles are 
passed around. Those cases would not only break the user experience, but would 
also provoke unusual software errors. Think also of the places where shared X 
infrastructure is expected, like interfacing with klipper (handles X 
clipboards) over D-Bus or with nspluginviewer, which does XEmbed.

In all, the only way to solve this problem is to forbid all types of multiple, 
simultaneous logins from all entry points. This includes SSH.

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

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20101110/2cb53175/attachment-0001.pgp>