[PATCH 2/2] qemu_shim: Ignore SIGPIPE

[Andrea Bolognani]

On Fri, 2020-02-28 at 16:56 +0100, Michal Privoznik wrote:
> I've found that if my virtlogd is socket activated but the daemon
> doesn't run yet, then the virt-qemu-run is killed right after it
> tries to start the domain. The problem is that because the default
> setting is to use virtlogd, the domain create code tries to
> connect to virtlogd socket, which in turn tries to detect who is
> connecting (virNetSocketGetUNIXIdentity()) and as a part of it,
> it will try to open /proc/${PID_OF_SHIM}/stat which is denied by
> SELinux:
> 
>   type=AVC msg=audit(1582903501.927:323): avc:  denied  { search } for  \
>   pid=1210 comm="virtlogd" name="1843" dev="proc" ino=37224 \
>   scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 \
>   tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dir \
>   permissive=0
> 
> Virtlogd reacts by closing the connection which the shim sees as
> SIGPIPE. Since the default response to the signal is Term, we
> don't even get to reporting any error nor to removing the
> temporary directory.

While I've been hitting this communication issue with virtlogd
consistently, I haven't been able to reproduce the exact sympthoms
you list: more specifically, the AVC doesn't show up in audit.log,
and virt-qemu-run not only reports the error but successfully cleans
up after itself.

[...]
> +++ b/src/qemu/qemu_shim.c
> @@ -150,6 +150,7 @@ int main(int argc, char **argv)
>      signal(SIGINT, qemuShimSigShutdown);
>      signal(SIGQUIT, qemuShimSigShutdown);
>      signal(SIGHUP, qemuShimSigShutdown);
> +    signal(SIGPIPE, SIG_IGN);

Either way, I'm not convinced this is the right fix: if virt-qemu-run
is unable to communicate with virtlogd, that is a serious issue that
should prevent the application from continuing. Or does this change
only make it so virt-qemu-run does not abort immediately but rather
gets far enough that it can report the error and clean up? Again, not
being able to reproduce the original issue locally makes it difficult
to validate the fix :)

-- 
Andrea Bolognani / Red Hat / Virtualization