similar to: [Bug 3] sshd fails to close open file descriptors when forking

I don't like to be the bearer of bad news, but... In light of the big "ssh hangs on logout" thread (wherein the true culprit was identified as being programs that don't close inherited file descriptors), I find it somewhat ironic that one of those "broken daemon" programs that doesn't close its open fds is sshd. :( http://bugzilla.mindrot.org/show_bug.cgi?id=3

https://bugzilla.redhat.com/show_bug.cgi?id=1123007 This is version 2 of the patch which avoids incorrectly closing stderr, so we can still see debug and error messages. Rich.

This refactors existing code to close file descriptors in the recovery process, and also adds code to close file descriptors between the fork() and exec() of QEMU or User-Mode Linux. The reason is to avoid leaking main process file descriptors where the main process (or other libraries in the main process) are not setting O_CLOEXEC at all or not setting it atomically. Python is a particular

http://bugzilla.mindrot.org/show_bug.cgi?id=3 ------- Additional Comments From markus at openbsd.org 2001-11-11 05:51 ------- isn't your software distribution program broken if it exec()s sshd without closing filedescriptors that might cause it break? ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.

The last (only?) caller of guestfs_int_cmd_clear_close_files() disappeared in commit e4c396888056 ("lib/info: Remove /dev/fd hacking and pass a true filename to qemu-img info.", 2018-01-23), part of v1.37.36. Simplify the code by removing guestfs_int_cmd_clear_close_files(). Signed-off-by: Laszlo Ersek <lersek at redhat.com> --- lib/guestfs-internal.h | 1 - lib/command.c

Hello All, I'm using OpenSSH 4.3p2 in HP-UX 11.23. On running tusc (a tool to trace system calls and signals) on sshd, I found lot of close calls upto 2047. Those close calls try to close a non-opened file descriptor and results in an error. This behaviour is seen only from OpenSSH 3.9 where closefrom() call is introduced to close the file descriptors before re-exec. The fix is to check

Hi Richard, I see this patch is included into libguestfs >= 1.26.6 & libguestfs >= 1.27.24. I feel that version is too high. Now RHEL 7.0 runs libguestfs-1.22.6, RHEL 6.6 alpha and 6.5 runs libguestfs-1.20.11. Is that possible to backport this patch, in order to make this problem fixed in RHEL 7.0, 6.6, and 6.5? Thanks & Best Regards Qin Zhao (赵钦) China System and Technology Lab,

https://bugzilla.mindrot.org/show_bug.cgi?id=2876 Bug ID: 2876 Summary: PAM_TEXT_INFO and PAM_ERROR_MSG conversation not honoured during PAM authentication Product: Portable OpenSSH Version: 7.7p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=3581 Bug ID: 3581 Summary: ssh-keyscan fails with `fdlim_get: bad value` with large file descriptor limit due to type confusion Product: Portable OpenSSH Version: 9.3p1 Hardware: ARM64 OS: Mac OS X Status: NEW Severity: enhancement

https://bugzilla.mindrot.org/show_bug.cgi?id=1213 --- Comment #37 from Daniel Richard G. <skunk at iSKUNK.ORG> 2011-11-25 12:40:45 EST --- Yet another failure mode... [...] # XXX.YYY.ZZ.8 SSH-2.0-Sun_SSH_1.1.3 # XXX.YYY.ZZ.9 SSH-2.0-OpenSSH_3.8.1p1 # XXX.YYY.ZZ.14 SSH-2.0-OpenSSH_4.3 # 10.10.1.35 SSH-2.0-RomSShell_4.62 Received disconnect from 10.10.1.35: 2: Protocol Timeout make: ***

I have an openssh RPM package that restarts the sshd server during an upgrade if the daemon is already running. So far, so good, restart works. But I observed the following behaviour: - when issuing rpm -Uvh bla.rpm, rpm, obviously, opens the rpm file and gets a file descriptor. Say, 8. - rpm does its stuff and spawns a shell to execute the %post script. The shell also gets fd 8 (should rpm

I have been trying to get rsync running correctly on cygwin for the past couple of days. I found a post on the cygwin list that said there was a bug in cygwin when using socketpair() but when I compiled the sample code: (http://jrepp.com/rsync/socketpair.c) both ways it works fine. Here's the article for reference: http://sources.redhat.com/ml/cygwin/2001-08/msg00357.html I am running the

http://bugzilla.netfilter.org/show_bug.cgi?id=793 Summary: ulogd -d does not close all fds Product: ulogd Version: SVN (please provide timestamp) Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ulogd AssignedTo: netfilter-buglog at lists.netfilter.org

Dear R developers, with the inclusion of the package "parallel" in the upcoming release of R, users and package developers are likely to make increasing usage of parallelization features. In part, these features rely on forking the R process. As ?mcfork points out, fork()ing in a GUI process is typically a bad idea. In RKWard, we "only" seem to have problems with signals

http://bugzilla.mindrot.org/show_bug.cgi?id=787 Summary: Minor security problem due to use of deprecated NGROUPS_MAX in uidswap.c (sshd) Product: Portable OpenSSH Version: 3.7.1p2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo:

Hi all, we were discussing internally how to make openssh leave open file descriptors that were open before main using LD_PRELOAD. Lately I filled upstream bugzilla [1] with proposed solution, that could be acceptable by upstream, but I'm also posting on this list to get more attention, other points of view or ideas for this case. I understand well, that closing FDs is important for

hi friends, I am using squid-2.5 and from last two days i m getting this error in cache log. i have increased ulimit from 1024 to 8192 but still i m getting error. pls give me suggestion how to overcome this problem. [root at gateway ~]# tail -f /var/log/squid/cache.log 2006/11/24 10:41:03| WARNING! Your cache is running out of filedescriptors 2006/11/24 10:41:19| WARNING! Your

http://bugzilla.mindrot.org/show_bug.cgi?id=787 ------- Additional Comments From openssh_bugzilla at hockin.org 2004-02-20 13:01 ------- Created an attachment (id=548) --> (http://bugzilla.mindrot.org/attachment.cgi?id=548&action=view) NGROUPS patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

From: "Richard W.M. Jones" <rjones at redhat.com> If the parent process uses a pipe (or any fd, but pipes are a particular problem), then the recovery process would hold open the file descriptor(s) of the pipe, meaning that it could not be fully closed in the parent. Because the recovery process doesn't use exec(2), this wasn't avoidable even using FD_CLOEXEC. Avoid this

Just wondering what it will take to get the nvidia binary driver working on a pv_ops kernel. It makes it difficult to debug without the source to the nvidia driver, but I think it should be possible to get it to work without changing the binary driver. If the dom0 kernel had access to all the resources that a bare metal kernel did, then it should work right? I''m using Jeremy''s