This is a discussion on Re: too many close calls for non-opened fds within the OpenSSH Development forums, part of the Networking and Network Related category; On August 16, 2006 5:57:15 PM -0400 Daniel Kahn Gillmor <dkg-openssh.com@fifthhorseman.net> wrote: &...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
On August 16, 2006 5:57:15 PM -0400 Daniel Kahn Gillmor <dkg-openssh.com@fifthhorseman.net> wrote:
> On August 16, carson@taltos.org said: > > > Does any UNIX variant have a "close all my open fds except for > > these" syscall? Or an easy way to get back a list of in-use fds? I > > really wish such a beast would be added, as calling close() on all > > possible fd numbers is _such_ a hack... > > While i understand the security advantage of this practice, it can > sometimes be ill-advised on systems that use external libraries which > have plugins, because you don't know what those plugins are going to > need. (alternatively, you could argue that a library with a plugin > architecture is itself less secure...) > > For example, some NSS (name service switch) extensions will use file > descriptors themselves (e.g. sockets to external LDAP resources), and > don't take kindly to them being killed mid-run. > > I ran into this problem with gdm a while back: > > http://bugzilla.gnome.org/show_bug.cgi?id=315846#c19 > > gdm had a similar "close_all_file_descriptors_except()" function, and > it was clobbering the LDAP connections that NSS was expecting to have > held open. I'd suggest that this is a bug in gdm that doesn't apply to openssh. If you're a system application and are going to close all fd's, you probably should fork/exec yourself immediately. As you said, you don't know what things are open on your behalf. But holding open an ldap connection (from a system library) across fork/exec is almost certainly wrong. In fact I'd be surprised if FD_CLOEXEC isn't set on the ldap fd's. -frank _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@mindrot.org http://lists.mindrot.org/mailman/lis...enssh-unix-dev |