Re: Passing FDs to activatable service

Hi

On Fri, Mar 15, 2019 at 3:01 PM Ernestas Kulik <[email protected]> wrote:
> On Thu, 2019-03-14 at 12:32 +0000, Simon McVittie wrote:
> > On Thu, 14 Mar 2019 at 10:08:08 +0100, Ernestas Kulik wrote:
> > > All those things work as one would expect, except for one
> > > particular
> > > case - running reportd as root, letting it activate abrt-dbus and
> > > calling SaveElements with a bunch of FDs (it makes sure to not go
> > > over
> > > 16). abrt-dbus receives the message with the UNIX_FDS header set
> > > accordingly, but the actual FDs never seem to arrive.
> >
> > D-Bus activation goes on a slightly weird code path: instead of being
> > able to deliver the message directly to abrt-dbus in its proper
> > sequence,
> > the message bus has to start abrt-dbus, and put the message in a data
> > structure. When it sees abrt-dbus request its well-known bus name,
> > the message bus has to remember that it had a message put aside for
> > abrt-dbus, retrieve it and re-attempt delivery. It's possible that
> > the
> > attached fds get lost somewhere along the way?
>
> Looks like I didn’t mention a couple other things: I don’t see this
> issue when doing session (reportd) <-> system (abrt-dbus), and system
> <-> system results in dropped FDs even after activation (but, again,
> not if I pop a root shell and run abrt-dbus there), so surely it can’t
> be hitting the same code path all the time?

Random thought: Does it also happen if you disable SELinux? SELinux
requires RW privileges to pass the fd on, which is really odd
sometimes.

> > If they do, I would consider that to be bug in whatever message bus
> > implementation you're using (usually dbus-daemon, but maybe dbus-
> > broker;
> > if in doubt ask your OS integrator).
>
> AFAIK, it’s dbus-broker in Fedora, but it happens with both? I tried
> disabling one and enabling the other in systemd, so not sure if that
> counts as switching between them.

Switching between them requires a reboot. You can check which one is
used through `systemctl status dbus`, which tells you either
`dbus-daemon.service` or `dbus-broker.service`.

> > If it's dbus-daemon, a regression test to dbus that demonstrates this
> > bug
> > would be very helpful. test/sd-activation.c would probably be the
> > best
> > starting point. Even if you don't have any particular interest in
> > systemd,
> > I've found that a mock implementation of systemd activation is easier
> > to
> > set up in a test than traditional activation, because the test can
> > "talk
> > to itself" and pretend to be all of: the client, the activatable
> > service,
> > and systemd.
>
> Thanks for the advice. I tried implementing a dummy service and client,
> but I can’t reproduce the issue with those, so I’m going crazy thinking
> that something is wrong with either reportd or abrt-dbus, but I can’t
> imagine what.

You use GDBus right? Do you use any non-standard features to play with
the marshalling?

Thanks
David
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus