Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!hao!nbires!isis!udenva!wedgingt
From: wedgingt@udenva.UUCP (Will Edgington)
Newsgroups: comp.unix.wizards
Subject: Re: /dev/stdin for 4.3?
Message-ID: <3745@udenva.UUCP>
Date: Sun, 31-May-87 23:58:26 EDT
Article-I.D.: udenva.3745
Posted: Sun May 31 23:58:26 1987
Date-Received: Wed, 3-Jun-87 03:52:20 EDT
References: <7359@brl-adm.ARPA> <5856@brl-smoke.ARPA> <15318@onfcanim.UUCP>
Reply-To: wedgingt@udenva.UUCP (Will Edgington)
Organization: U of Denver
Lines: 49

In article <15318@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes:
> [ discussing how to implement /dev/fd*, /dev/std{in,out,err} ]
>
>I believe it's better to do the equivalent of a full dup(), returning
>a newly-opened descriptor.  You still need only an open() entry,
>but you have to alloc an ofile table slot and increment the reference
>count on the file struct.
>
>[...]
>
>Now, you can also argue that a new file struct should be allocated too,
>exactly the same as would happen if you really open()ed the same file
>twice.  However, I think this less likely to cause trouble,

Slightly !  If you really open it, think about what happens with
something like :

% cat /etc/passwd | 1and2 /dev/stdin /dev/stdin

where the program '1and2' takes one line from it's first argument,
prints it, 2 lines from it's second arg, prints them, and goes
back to one line from it's first arg (something like serial merging
of already sorted data) ...  You're trying to use the data from the
pipe *twice* !!!  Certainly, whoever's doing this will be mighty
surprised when he merely gets the password file as output (which is
what I *think* would happen).  Of course, since pipes are implemented
as sockets under BSD 4.[23] (I'm not sure about 4.1), you can't
open() it twice anyway.  Of course, doing the open() indirectly like
this may mean the kernel can't tell it's a socket until too late ...
In any case, the semantics are a MESS.

>and having
>the two logically-separate units sharing the same seek pointer may
>actually be useful sometimes.

Yes ...

While I'm here, I seem to remember something about file descriptor
drivers like this being security holes in certain cases.  Anyone
care to elaborate on this aspect (probably again) ?  I'm on the
Security mailing list, also, if you'd prefer to go that route
(in fact, the Security list's moderator is on another Univ. of
Denver site; his address is {hao,nbires}!udenva!isis!aburt).
-----
Will Edgington, Computing and Information Resources, University of Denver
System Administrator for udenva (== dueos), dutyche, duorion, dunike, ...
{{hplabs,seismo}!hao,ucbvax!nbires,boulder,cires,ssds}!udenva!wedgingt,
WEDGINGT@DUCAIR (BITNET), wedgingt@ccndu (CSN/CCN), ...
COMING SOON: wedgingt@du.edu (all nets)|"No two addresses are the same ..."