Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site rtgvax.UUCP
Path: utzoo!linus!decvax!decwrl!pyramid!pesnta!amd!amdcad!cae780!leadsv!rtgvax!ksh
From: ksh@rtgvax.UUCP (Kent S. Harris)
Newsgroups: net.unix-wizards
Subject: Re: Conventional daemons
Message-ID: <44@rtgvax.UUCP>
Date: Tue, 1-Apr-86 17:48:27 EST
Article-I.D.: rtgvax.44
Posted: Tue Apr  1 17:48:27 1986
Date-Received: Sat, 5-Apr-86 03:36:11 EST
References: <2177@brl-smoke.ARPA>
Organization: Santa Clara Valley Computer Sciences, Cupertino, CA
Lines: 16

In article <2177@brl-smoke.ARPA>, bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) writes:
> 
> ...why do they open "/" on stdin/stdout...
> ...
> The real question was, why open anything? Surely there's
> nothing functionally useful about opening stdin/stdout on
> "/" and it could be a potential hazard if ported.
> ...
Yes, I believe there is.  I've not followed this all the way to ground
state, but I recall deep within the cobwebs something about stdio having
some hard coded constants reguarding fd's < 3 (I know the kernel doesn't
give two hoots about particular fd's).  The idea is to close
all fd's, open "/", and dup this fd to 1 and 2 so any new opens will
be allocated fd's >= 3.  Doing file stream i/o via stdio where an fd < 3
has been allocated seems to send data to ye old bit bucket (empirically
determined).  Let's hear from someone with a definitive answer.