Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 13 Apr 2002 18:18:16 -0700
From: Jon Travis <jtravis@covalent.net>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: dev@apr.apache.org
Subject: Re: Unix missing fd 0..2, Win32 service missing stdin/out/err handles
Message-ID: <20020413181816.A4947@covalent.net>
References: <5.1.0.14.2.20020413125703.021ef950@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <5.1.0.14.2.20020413125703.021ef950@localhost>;
 from wrowe@rowe-clan.net on Sat, Apr 13, 2002 at 01:20:25PM -0500

On Sat, Apr 13, 2002 at 01:20:25PM -0500, William A. Rowe, Jr. wrote:
> A suggestion to implement in apr_app_initialize, but first some background.
> 
> Without harming apr_initialize(), which should continue to be useful
> for initializing apr in a non-apr application (e.g. a mod_jk connector built
> with apr, that is written for Apache 1.3), I had started an apr_app_initialize
> a while back.
> 
> One paragraph of background; I created apr_app_initialize primarily to allow
> us to use the apr signals API... if we detect the app is running in a console,
> we can set up the Windows console API in the signal schema.  If we detect
> we are running 'as a service', we can set up the Windows SCM context
> immediately, and when apr_daemonize is invoked, we can report 'started'.
> We also use apr_app_initialize on Win32 to transform our Unicode input
> (command line args and the environment table) into utf-8 internal encoding.
> So far, so simple [yet I haven't had three days to put the signals together.]
> 
> Back to the purpose of this post;
> 
> 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.
> 
> 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.
> 
> 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.

-- Jon