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