apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Unix missing fd 0..2, Win32 service missing stdin/out/err handles
Date Sun, 14 Apr 2002 05:29:37 GMT
At 08:18 PM 4/13/2002, Jon Travis wrote:
>On Sat, Apr 13, 2002 at 01:20:25PM -0500, William A. Rowe, Jr. wrote:
> > Because third party libraries have a nasty habit of dropping messages out
> > to stderr or stdout... and will sometimes even poll stdin (think 
> passphrases
> > or other bits in encryption libraries, etc) ... it is rather dangerous for
> > -our- applications to ever use fd 0..2.  Sure, you can chalk it up to a 
> bug in
> > the caller, but imagine if 'by chance' we open up an sdbm as fd 2.  Another
> > library prints something to stderr and bang ... database is corrupted.

> > So, on the unix side, within apr_app_initialize, I suggest calling
> > fopen("/dev/null", ) until it returns an fd >2.  On the Win32 side, I 
> suggest
> > calling GetStandardHandle() and filling in any missing stdhandles with
> > the appropriate FILE*'s fd's handle after opening 'NUL' in the clib, so all
> > three bases are covered.  If we end up with an fd >2, then we immediately
> > close that last /dev/null file and go on.
> >
> > Does this make good sense?
>Not particularly.
>The operating system pre-allocates those fd's (0..2 for Unix) -- why would
>opening an SDBM ever return any of those file descriptors?  The only way
>would be if the consumer closed those handles beforehand.  If the user
>does something like that, their program is broken -- we shouldn't try
>to work around that.

That's the sort of feedback I was looking for.  Thanks.  Yes - if it succeeds
in opening fd 0..2 then the caller fooed up.  And if we don't care to protect
against that case, I can go along with that.  However...

> > On the Win32 side, same goes for FILE *'s stdin, stderr and stdout, for
> > the low level 'fd's 0..2 (not really fd's as unix knows them, but the 
> clib's
> > table of Win32 handles), and the Win32 standard handles.  Win32 services
> > have -no- STD handles, even when they are command line apps.

This is the operating system's responsibility - and it won't happen on Win32
services.  So in the Win32 case, I see this as required.


View raw message