On Thu, Mar 05, 2020 at 10:06:53AM +0100, Andrea Bolognani wrote:
> 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 :)
Regardless of the actual problem faced, ignoring SIGPIPE is the right
thing todo for all programs. They'll then process normal error returns
from write()
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
