[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rpm leaks an fd in install/erase scripts



Frank Cusack wrote:

I brought this up wrt openssh a long time ago, on the openssh list.
I did have a positive response (positive = will fix) from some rpm
person (not Jeff), but this seems to still be broken as of RH9.



Presumably you mean "has an open fd", rather than "forgets to close"
for "leak". I find it hard to believe that 1 fd per scriptlet execution is lost.


If  there's a file descriptor open, it's a rdonly file descriptor positioned
at the end of the payload. I'm not really sure that's a problem.

If you mean that sshd is carrying an open file descriptor, then there's
a missing FD_CLOEXEC that's missing in fdDup() on the payload
file descriptor. I'll take a look ...

IMHO, sshd really needs to be fixed to close file descriptors when
restarted. It's not just rpm %post, and open file descriptors will
remain when sshd is restarted from other contexts. That can be fixed
most easily by closing file descriptors in sshd, not trying to fix each
and every context that might restart sshd.

'ssh remotehost sleep 10 & exit' doesn't exit for 10s on Linux.  This
is because of kernel behavior which doesn't send HUP to background
processes when the fg process exits, and openssh doesn't exit until
all read fd's have closed.  That's (arguably) correct behavior.

rpm leaks a dup'd fd to %post et al. scripts.  If a %post (say) [re]starts
a daemon which only closes fd's 0,1,2, then a command like
'ssh remotehost rpm -ivh package.rpm' will hang indefinetely, since stdout
is still open (daemon running in the bg has the dup'd fd open) and sshd is
waiting for input.

Are folks aware of this bug?  If I submit a patch, is it likely to be
applied?  I'd rather not have to dig through the rpm code although I
will do so if you'll accept a patch and don't have time to look for
it yourself.


The fix is probably in rpmio/rpmio.c, look for dup call, set FD_CLOEXEC immediately after, if my guess above is correct.

73 de Jeff




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []