RE: Apache 2.x leaked descriptors

[Michael Wojcik <Michael.Wojcik () microfocus com>]

> From: Steve Grubb [mailto:linux_4ever () yahoo com] 
> Sent: Monday, February 24, 2003 8:26 AM

> There are ways to stop virtual hosted sites from having access to
> their neighbors or even having direct access to their own log 
> files. This can be done through chroot, a sandbox, or jail. The
> problem is that all of these protection mechanisms breakdown if
> you inherit an open descriptor.

Agreed; they may not all directly "break down", depending on how you want to
define that, but certainly inherited descriptors are a security problem in
general.

However:

> The jail or sandbox would have to fstat thousands of file
> descriptors to see if they are open and close them before exec'ing
> the cgi.  This is a performance hit and therefore unlikely.

No need to fstat them merely to see if they're valid; closing an invalid
descriptor doesn't hurt anything on any POSIX platform I know of.

Still, depending on the maximum descriptor number available to the process
(which should be determined via sysconf, since many platforms allow
per-process maximums; it's a ulimit in AIX 5, for example), just closing
descriptors 3-max may be a significant operation.  I vaguely recall a Samba
fix some years ago for AIX for this reason - _POSIX_OPEN_MAX or NFILES or
some such system define was a very high number, and each child smbd process
was trying to close thousands of descriptors before doing any real work.

Some platforms provide a way to whack lots of descriptors in one go; AIX has
fcntl(3, F_CLOSEM, 0), which is pretty handy.

I think the real way to fix this for CGI is to have the parent process set
the F_CLOEXEC flag on all the descriptors it opens, except those that the
child is supposed to inherit.  Then there's no performance bottleneck, just
one additional system call each time a new descriptor is allocated (via
open, accept, etc).

There are a couple of problems with this approach: it requires vigilance on
the part of the developer (but what doesn't, and some profiling with lsof
can catch most omissions), and some poorly-designed APIs allocate
descriptors but don't tell the caller what they are.  A notorious example is
the brain-damaged POSIX openlog/syslog API, which has void return type
instead of something useful.  If openlog is implemented in the obvious
fashion, the app should be able to guess what descriptor it's allocated (it
should have been the lowest available one), and in any case can find it with
some hunting and testing, but it's probably best to avoid syslog or call
closelog after every syslog call.

Michael Wojcik
Principal Software Systems Developer, Micro Focus