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.
Bill
