On Mo, 29.06.20 12:19, Ian Pilcher (arequip...@gmail.com) wrote:

> I originally posted a variation of the question on the SELinux mailing
> list, but the more I look at this the more I realize that it really
> isn't a SELinux questions.  I'm not really sure that it's a systemd
> question either, but it definitely falls into the area of Linux process
> management, so I'm hopeful that someone here at least has an idea what
> is going on ...
> I'm in the (hopefully) final stages of creating the policy module for a
> daemon that I've written to monitor my home NAS.
> The daemon is started by systemd (init_t) and runs as its own type
> (freecusd_t).  In order to read the SMART attributes of the NAS drives,
> the daemon runs a helper application, which has its own type
> (freecusd_smart_t).  So:
>   systemd (init_t) --> freecusd (freecusd_t)
>                            --> freecusd_smart_helper (freecusd_smart_t)
> I've got my policy basically working, but I'm getting this SELinux
> denial, which I just don't understand:
> type=AVC msg=audit(1593392372.230:9215): avc:  denied  { sigchld } for pid=1
> comm="systemd" scontext=system_u:system_r:freecusd_smart_t:s0
> tcontext=system_u:system_r:init_t:s0 tclass=process permissive=0
> This seems to be saying that the helper is trying to send SIGCHLD to
> systemd.  I'm seeing this message repeated 4 times when the freecusd
> daemon starts and then sporadically afterwards.  (freecusd repeatedly
> spawns the helper to read the drive states.)
> Is there a circumstance in which the grandchild (freecusd_smart_helper)
> would send SIGCHLD to systemd while its parent is still running?

Maybe it double forks or forks a child off (callout script?) that
double forks somewhere?

I don't know your software, it's probably best to ping the authors of
it about this, they should know what their software does.


Lennart Poettering, Berlin
systemd-devel mailing list

Reply via email to