This is a discussion on Re: too many close calls for non-opened fds - openssh ; On August 16, 2006 5:57:15 PM -0400 Daniel Kahn Gillmor wrote: > On August 16, email@example.com said: > > > Does any UNIX variant have a "close all my open fds except for > > these" syscall? Or an easy ...
On August 16, 2006 5:57:15 PM -0400 Daniel Kahn Gillmor
> On August 16, firstname.lastname@example.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:
> 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.
openssh-unix-dev mailing list