Starting the kdbus discussions

[Lennart Poettering]

On Tue, 07.01.14 10:50, Thiago Macieira (thiago at kde.org) wrote:

> On sexta-feira, 3 de janeiro de 2014 12:45:51, Simon McVittie wrote:
> > Assuming that system services want to be able to upgrade from a dbus
> > environment to a kdbus environment without a distro-wide flag day,
> > they'll need to keep installing their policy XML until they no longer
> > support *upgrading from* non-kdbus systems.
> > 
> > In practice, since kdbus is recent-Linux-specific, it seems desirable to
> > have a solution where it is harmless for portability-minded upstreams to
> > continue to install policy XML, which will still be needed on old-Linux
> > or non-Linux. Linux-only system integrators who no longer support
> > upgrading from a non-kdbus system could safely delete it to save some
> > disk space, of course.
> 
> Please bear in mind that you said "upgrade [...] to a kdbus environment", 
> "since kdbus is recent Linux-specific", "non-kdbus", etc.
> 
> I think the solutions discussed for the policy and access restrictions are 
> going in the right direction. Doing either an untrusted system bus request or 
> enforcing the policy in the client library are workable solutions.
> 
> However, the discussion started with the activation files. The kernel side of 
> kdbus does not support activation and that's what defines what kdbus is. The 
> activation is performed by the userspace complement. So how does one port from 
> dbus-daemon activation files to kdbus activation files?

Well, you don't have to, that's option #1, in which case everything will
work fine, the oldXML policy and you will connect via the old proxyd.

Or you choose to convert. In this case you have two options: one is to
provide native systemd unit files which is the only option we'll support
on systemd for the system bus. For the user bus however, we want to open
a second option which also gets rid of the old dbus1 activation
files. And that is via .desktop files, that contain bus
DBusActivatable=yes (as included in the most recent version of the
.desktop file format, added by Ryan), as well as Exec= and NoDisplay=. 

This would only be a minimal extension to the .deskop file standard
(since currently it says that DBusActivatable=yes .desktop files should
not contain Exec= unless they add it for compat for old desktops), but
certainly simplify things as the requirement for .desktop files to
always be accompanied by dbus1 activation files could be dropped.

I am sorry, but I see no future for dbus1 service activation
files. Either use native systemd unit files as for any other system
services, or use .desktop files, but dbus1 service activation
files appear unnecesary.

> Please be careful because the only solution we have so far is to use systemd 
> unit files, which require rephrasing your two paragraphs above and replace 
> "kdbus" with "systemd". I don't want to enter the merits of systemd versus 
> alternatives in this mailing list, since it does not belong here at all. We 
> simply have to accept that, as of 2014, relying on systemd is not an 
> acceptable solution.

Well, if you write a system service you should be willing to integrate
it cleanly into the system. And on systemd systems that system is
largely defined by systemd. The largest part of system services ship
both dbus1 activation fiels, and native systemd units already (on Fedora
at least), so this isn't too much of a change, and we are perfectly
compatible anyway...

I mean, note that for all other system services but bus activatable we
are in that situation anyway: you need to ship sysv, systemd and upstart
files if you want it to start up on all those systems. I simply believe
that dbus system bus activated services shouldn't be treated that
differently from other system services.

The reason why we make this requirement is that the kdbus policy is
embedded into the .busname unit files: you configure th policy for a
name right next to where you'd configure activation for it.

> So I have to ask of Lennart and Kay: would it be acceptable for systemd to 
> convert on-the-fly from a generic activation format to systemd units? And if 
> so, could we keep the current .service files with maybe an additional key 
> indicating that an "insecure system bus" is acceptable?

Again, on systemd systems we provide full compatibility anyway, we do
honour dbus1 activation files, but only for connections via the proxy,
i.e for the same cases where the old XML policy is supported. But if you
talk directly to kdbus, then nope, no dbus1 actviation files. Sorry.

Lennart

-- 
Lennart Poettering, Red Hat