Starting the kdbus discussions

[Lennart Poettering]

On Wed, 01.01.14 22:24, Kevin Krammer (krammer at kde.org) wrote:

> On Monday, 2013-12-30, 21:08:35, Lennart Poettering wrote:
> > On Sun, 29.12.13 23:12, Ted Gould (ted at gould.cx) wrote:
> 
> > > > Well, it's not that different from today. On Fedora at least we ship a
> > > > systemd service file each for all bus-activated system service these
> > > > days,
> > > > and the dbus activation files are mostly just compatibility. So they
> > > > already are systemd unit files, and they just continue to be, its just a
> > > > bit more mandatory.
> > > 
> > > I'll take that as: "No, service files will not be supported in any
> > > way."
> > 
> > Old dbus1 service files are supported, but only for clients that connect
> > indirectly via the bus proxy. There's a systemd "generator" in place
> > that simply convers the old dbus1 service files into a pair of systemd
> > unit files each.  Modern clients that speak kdbus directly need to
> > provide unit files.
> 
> Assuming the latter also applies to software using the ported GDBus and 
> libdbus1 libraries (or wrappers of those), what kind of information measures 
> are you planning in order to reach them and/or what kind of diagnostic 
> facilities will be in place that alert them of the changed requirements during 
> build or runtime?

Note sure I really understood your question, but I think you are asking
how an app should deal with the fact that gdbus might transparently get
updated to a different backend, which even though everything still
compiles fine suddenly makes different requirements regarding activation
files to install?

If this is the question, then there's actually an even bigger problem
related to this: as mentioned we made some changes regarding policy
enforcement for the system bus: the old XML policy is only enforced in
the bus proxy, it is not enforced in natvie kdbus clients. We expect
native kdbus services to enforce their own per-method policy, either via
PolicyKit or by simply checking client uid/caps. Now, if a classic dbus1
service using gdbus with no change at all in its source code would
connect directly to kdbus it would be totally insecure: since classic
dbus1 services enforce zero policy on their own, they'd be wide open for
anyone. This means that existign software that currently connects to
dbus1 must be prepared for enforcing its own policy before it can be
allowed directly on kdbus.

The way I'd suggest that bus APIs solve this is by making applications
indicate to the bus library they use whether they do their own security
checks. And if an app does not explicitly tell a library "I do my own
security checks" then the library would connect via the socket transport
rather than kdbus directly in order to take benefit of the bus proxy's
enforcement of the old XML policy.

Or more specifically, for libdbus1 I'd propose to add
dbus_bus_get_untrusted() in addition to dbus_bus_get(). The latter would
only allow connections to busses which are either owned by the same user
(for session busses) or that enforce full per-method policy on their
own. The former however would be the one that can talk directly to kdbus
system busses, since when called implies the acknowledgment of the
caller that it has to do its own access control because it is on an
"untrusted" bus.

Note that all what I discuss above only really applies to the system
bus, since the user bus knows no policy and all clients that can connect
to it at all are trusted anyway. For user bus clients the entire problem
set goes away.

Coming back to the original question (or what I think the question was):
I figure the trusted/untrusted thing is also something that would
translate to whether people should ship unit files or dbus1 service
activation files. (That all said, thinking about it, maybe we should
just drop the requirement for native unit files or the user bus, and
just keep it in for the system bus).

Lennart

-- 
Lennart Poettering, Red Hat