Starting the kdbus discussions

Thiago Macieira thiago at kde.org
Tue Jan 7 09:50:56 PST 2014


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?

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.

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?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140107/eff33618/attachment.pgp>


More information about the dbus mailing list