Passing FDs to activatable service

[Ernestas Kulik]

Pn, 2019 03 15 15:09 +0100, David Rheinsberg rašė:
> Hi
> 
> On Fri, Mar 15, 2019 at 3:01 PM Ernestas Kulik <
> ernestas.kulik at gmail.com> 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.

/me sighs.

I almost started jumping out of joy, because that worked. Disabling
dontaudit rules also revealed a lot of screaming in the journal (gdbus
being denied read access to the files). Now that the devil is known, I
can deal with it (not letting reportd use $XDG_RUNTIME_DIR blindly and
default to /root/.cache might be good for everyone involved).

Thanks for the random thought!

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