[systemd-devel] Compatibility between D-Bus and kdbus

[Lennart Poettering]

On Wed, 26.11.14 10:04, Thiago Macieira (thiago at kde.org) wrote:

> On Wednesday 26 November 2014 12:27:16 Lennart Poettering wrote:
> > > Please also note that the autostart solution has a valid use-case which is
> > > when a D-Bus application is launched in an environment where no bus had
> > > been started before. I understand this is out-of-scope for kdbus, since
> > > after all a regular user won't be able to create a kdbus bus if one
> > > wasn't provided by a privileged process before. In an environment where a
> > > kdbus bus wasn't provided, the only alternative is to fallback to dbus1.
> > 
> > Hmm? Creating busses requires no privileges. Users create their own
> > busses without requiring any kind of privilege for that.
> 
> How is that secure? That would imply that any process, with any UID, can issue 
> KDBUS_CMD_BUS_MAKE for a bus name that another UID would expect to use.
> 
> I must be misunderstanding something.

The kernel enforces that each bus name is prefixed with "$UID-". This
is why the system bus is /sys/fs/kdbus/0-system rather than just
/sys/fs/kdbus/system.

This makes sure that users cannot play games with other users.

> > > > Note that on dbus1 systemd systems we actually never provided
> > > > UpdateActivationEnvironment correctly (since services got forked off
> > > > PID 1, instead of dbus-daemon but the call would alter dbus-daemon's
> > > > env block, not systemd's one), but nobody ever noticed. I really
> > > > think you should just return some "not supported" error or make it a
> > > > NOP if you don't want to pass this on to systemd.
> > > 
> > > I *want* to pass this to systemd, somehow. So the first question is
> > > whether we can expect there to be a connection by systemd in the buses it
> > > creates. On the system bus, there's org.freedesktop.systemd1 so I expect
> > > that to continue. Can we expect a similar service on systemd-user buses?
> > 
> > Yes. systemd creates the bus and then acquires
> > org.freedesktop.systemd1 on it, and does this for both the system and
> > the user bus the same way.
> 
> My argument was for a more generic name, such as something in the 
> org.freedesktop.DBus hierarchy. That way, if someone else wants to provide 
> kdbus-powered buses, they'd implement that interface instead of trying to 
> emulate systemd and playing catch-up and possibly bug compatibility.

I am really not keen in defining a new abstract bus interface for two
functions of which at least one is very questionnable anyway, and
where it's not clear that there will ever be a second implementation
of...

I mean, the two operations are not even really abstractable since both
the update-env stuff and the reload stuff have different semantics on
systemd: they are much more comprehensive and apply to all services at
once instead of just the bus services. I mean, it sounds OK to me to
pass this to systemd for compat reasons in a quirky way. But it if we
define an abstract, well-defined, standardized interface for this with
inherently unclean semantics this is really nothing I want to do.

> Further, if it does acquire the org.freedesktop.DBus name itself, libraries 
> won't have to emulate most of the compat behaviour by intercepting outgoing 
> messages. Intercepting means EVERY message needs to be inspected at one point 
> or another, instead of letting it fallback when the call actually happens. In 
> other words, providing a fallback service optimises for the right
> use-case.

This kind of half/half solution sounds messy to me. Either emulate it
or don't. But having some of the calls emulated on the client-side and
some elsewhere sounds messy.

> > There's an ioctl for that too, that the creator can then call on the
> > fd it has open.
> 
> I guess I got confused by the wording of what you can do with what file 
> descriptors. I was under the impression that you'd need three file descriptors 
> for a bus or an endpoint to make any useful use
> 
>  1) one fd that opened the "control" file (to create a bus) or to the bus (to 
> create the endpoint)
>  2) one fd that you'll want to open the bus/endpoint on so you can later send 
> updates to the policies
>  3) one fd to actually do talking on
> 
> My confusion was that the doc says that after CMD_xxx_MAKE the file descriptor 
> can't be used again. 5.3 says "... is file descriptor will manage the newly 
> created endpoint resource. It cannot be used to manage further resources." I 
> guess I read "further resources" as including changing policies on this 
> bus/endpoint.
> 
> Thanks for the clarification. I recommend adding a section on what steps to do 
> to create a bus (including setting up policies, activators), one on creating 
> an endpoint, and then one on how a controlling process should operate to 
> manage the bus/endpoint properly.

To create a bus you open the "control" file, issue an ioctl (MAKE_BUS)
on the fd, and the fd is then *converted* into a reference to the
bus. You can use it then only for updating policy and for eventually
closing it to make the bus go away.

To create a bus connection you open the bus file, issue an ioctl
(HELLO) on the fd, and the fd is then *converted* into a connection
fd. You can then use that for send/recv messages, or
acquiring/releasing names.

To create a bus EP you open the bus file, issue an ioctl (MAKE_EP) on
the fd, and the fd is then *converted* into a reference to the EP. You
can use it then only to update the EP's policy, and for eventually
closing it to make the EP go away.

The systemd PID 1 instance has only two fds open hence: one bus
reference, and one bus connection.

A sandboxing app executor has one, maybe two fds open: the EP
reference, and maybe a bus connection in case it wants to offer some
services...

> > Well, but in those cases you can just use the user bus or system bus,
> > there's no need to create a new bus just for the purpose of P2P...
> 
> That implies changes to the user application. I want to provide a replacement 
> API for DBusServer.

So, if this is about compat with old apps then continue to use AF_UNIX
for that... No need to push them to something new...

Lennart

-- 
Lennart Poettering, Red Hat