Bug 37695

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.14-12 i686)


In runScript() in lib/psm.c (in the current CVS repository; this would be
in lib/uninstall.c in rpm 4.0.2), a duplicate of STDOUT_FILENO is created
if ts->scriptFd is not set, which is the normal case.  (Oddly, there is
logic for conditionalizing on rpmIsVerbose() when ts->scriptFd is set, but
no such logic otherwise.)  The child process does not close "out" when
scriptFd is unset, so the script processes run with a duplicate of
STDOUT_FILENO in their space.

This odd behavior can lead to problems if the script starts a daemon
process, even a well-behaved daemon which closes fds 0, 1, and 2.  (Some
daemons close all fds, but I don't think there is any consensus that a
daemon is required to do this.)  In that case, the daemon process will
still have a reference to rpm's output fd in its file table, so if rpm
output was passed through a pipe, the right side of the pipe will never
terminate.

We don't see this problem in Red Hat RPMs on a modern system because
/sbin/initlog (used by "daemon" in initscripts) now closes all file
descriptors >= 3 before running the daemon process.  This was not always
so, and I have encountered hanging pipeline problems upgrading from Red Hat
6.2 or Red Hat 7.0 to Red Hat 7.1 because RPMs like "at" and "gpm", if they
happen to be upgraded by the transaction before initscripts is upgraded,
will restart their daemons with the daemon process holding the pipe open.

The fix is pretty easy.  Either stop creating "out" when ts->scriptFd isn't
set (and conditionalize the parent's close of "out" on ts->scriptFd being
set), or move the child's close of "out" outside of the ts->scriptFd
conditional.

Reproducible: Sometimes
Steps to Reproduce:
As noted in the description, producing an actual problem is kind of
difficult due to all the players involved like /sbin/initlog.  Hopefully my
exposition of the bug is sufficient to show its presence.