libvirt/tests/commanddata/test20.log

ARG:--close-stdin
ENV:DISPLAY=:0.0
ENV:HOME=/home/test
ENV:HOSTNAME=test
ENV:LANG=C
ENV:LOGNAME=test
ENV:PATH=/usr/bin:/bin
ENV:TMPDIR=/tmp
ENV:USER=test
FD:0
FD:1
FD:2
DAEMON:no
CWD:/tmp
UMASK:0022
command: avoid deadlock on EPIPE situation It is possible to deadlock libvirt by having a domain with XML longer than PIPE_BUF, and by writing a hook script that closes stdin early. This is because libvirt was keeping a copy of the child's stdin read fd open, which means the write fd in the parent will never see EPIPE (remember, libvirt should always be run with SIGPIPE ignored, so we should never get a SIGPIPE signal). Since there is no error, libvirt blocks waiting for a write to complete, even though the only reader is also libvirt. The solution is to ensure that only the child can act as a reader before the parent does any writes; and then dealing with the fallout of dealing with EPIPE. Thankfully, this is not a security hole - since the only way to trigger the deadlock is to install a custom hook script, anyone that already has privileges to install a hook script already has privileges to do any number of other equally disruptive things to libvirt; it would only be a security hole if an unprivileged user could install a hook script to DoS a privileged user. * src/util/command.c (virCommandRun): Close parent's copy of child read fd earlier. (virCommandProcessIO): Don't let EPIPE be fatal; the child may be done parsing input. * tests/commandhelper.c (main): Set up a SIGPIPE situation. * tests/commandtest.c (test20): Trigger it. * tests/commanddata/test20.log: New file. 2012-05-31 15:50:07 -06:00			`ARG:--close-stdin`
			`ENV:DISPLAY=:0.0`
			`ENV:HOME=/home/test`
			`ENV:HOSTNAME=test`
			`ENV:LANG=C`
tests: fix typo Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> 2017-11-17 16:17:38 +03:00			`ENV:LOGNAME=test`
command: avoid deadlock on EPIPE situation It is possible to deadlock libvirt by having a domain with XML longer than PIPE_BUF, and by writing a hook script that closes stdin early. This is because libvirt was keeping a copy of the child's stdin read fd open, which means the write fd in the parent will never see EPIPE (remember, libvirt should always be run with SIGPIPE ignored, so we should never get a SIGPIPE signal). Since there is no error, libvirt blocks waiting for a write to complete, even though the only reader is also libvirt. The solution is to ensure that only the child can act as a reader before the parent does any writes; and then dealing with the fallout of dealing with EPIPE. Thankfully, this is not a security hole - since the only way to trigger the deadlock is to install a custom hook script, anyone that already has privileges to install a hook script already has privileges to do any number of other equally disruptive things to libvirt; it would only be a security hole if an unprivileged user could install a hook script to DoS a privileged user. * src/util/command.c (virCommandRun): Close parent's copy of child read fd earlier. (virCommandProcessIO): Don't let EPIPE be fatal; the child may be done parsing input. * tests/commandhelper.c (main): Set up a SIGPIPE situation. * tests/commandtest.c (test20): Trigger it. * tests/commanddata/test20.log: New file. 2012-05-31 15:50:07 -06:00			`ENV:PATH=/usr/bin:/bin`
tests: fix typo Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> 2017-11-17 16:17:38 +03:00			`ENV:TMPDIR=/tmp`
command: avoid deadlock on EPIPE situation It is possible to deadlock libvirt by having a domain with XML longer than PIPE_BUF, and by writing a hook script that closes stdin early. This is because libvirt was keeping a copy of the child's stdin read fd open, which means the write fd in the parent will never see EPIPE (remember, libvirt should always be run with SIGPIPE ignored, so we should never get a SIGPIPE signal). Since there is no error, libvirt blocks waiting for a write to complete, even though the only reader is also libvirt. The solution is to ensure that only the child can act as a reader before the parent does any writes; and then dealing with the fallout of dealing with EPIPE. Thankfully, this is not a security hole - since the only way to trigger the deadlock is to install a custom hook script, anyone that already has privileges to install a hook script already has privileges to do any number of other equally disruptive things to libvirt; it would only be a security hole if an unprivileged user could install a hook script to DoS a privileged user. * src/util/command.c (virCommandRun): Close parent's copy of child read fd earlier. (virCommandProcessIO): Don't let EPIPE be fatal; the child may be done parsing input. * tests/commandhelper.c (main): Set up a SIGPIPE situation. * tests/commandtest.c (test20): Trigger it. * tests/commanddata/test20.log: New file. 2012-05-31 15:50:07 -06:00			`ENV:USER=test`
			`FD:0`
			`FD:1`
			`FD:2`
			`DAEMON:no`
			`CWD:/tmp`
command: test umask support Add testsuite coverage for the recent commit 0e1a1a8. * tests/commandhelper.c (main): Output umask. * tests/commandtest.c (test15): Also test umask. (mymain): Add test. * tests/commanddata/*.log: Update expected output. Signed-off-by: Eric Blake <eblake@redhat.com> 2014-09-03 09:13:21 -06:00			`UMASK:0022`