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

[Thiago Macieira]

On Wednesday 26 November 2014 19:30:16 Lennart Poettering wrote:
> > 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.

Thanks for the clarification. That tidbit is nowhere in the kdbus.txt docs. It 
should probably be mentioned in the section about creating buses.

Also, shouldn't CAP_IPC_OWNER-privileged processes be able to create a bus 
with an arbitrary  name?

> > 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 understand that reluctance.

> 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.

Well, whatever it is, we need a sane API. I'm willing to standardise on the 
systemd behaviour if the current one is quirky anyway. If we do that, we'll 
need a new interface name anyway.

> > 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.

I don't want to emulate any in the library. Any calls that are made are sent 
to the service. AddMatch and RemoveMatch would reply with error, but most of 
the others should just work.

But given the other email, I guess I am only looking at my own problem. I 
didn't know that other applications, using other bindings, had legitimate uses 
for calling AddMatch directly.

> > 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...

Understood. My recommendation for clarification in kdbus.txt remains.

> > > 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...

Well, one thing I've just realised is that the other app needs to know about 
kdbus too. So we have a double compat issue.

Still, I think that a binding *can* provide a P2P-style bus by abusing 
endpoints with just a bit of convention rules.

-- 
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