Date: Mon, 1 May 2000 09:05:08 -0700
From: Zack Weinberg <zack AT wolery DOT cumb DOT org>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: Nate Eldredge <neldredge AT hmc DOT edu>, djgpp-workers AT delorie DOT com,
        lauras AT softhome DOT net, gcc-patches AT gcc DOT gnu DOT org
Subject: Re: Minor DJGPP fixes
Message-ID: <20000501090508.L11780@wolery.cumb.org>
References: <390C769C DOT 812EAB7D AT softhome DOT net> <20000501000928 DOT J11780 AT wolery DOT cumb DOT org> <200005010837 DOT EAA00013 AT indy DOT delorie DOT com> <14605 DOT 19595 DOT 491155 DOT 235037 AT mercury DOT st DOT hmc DOT edu> <200005011025 DOT GAA00121 AT indy DOT delorie DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.12i
In-Reply-To: <200005011025.GAA00121@indy.delorie.com>; from eliz@delorie.com on Mon, May 01, 2000 at 06:25:18AM -0400
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Mon, May 01, 2000 at 06:25:18AM -0400, Eli Zaretskii wrote:
>    From: Nate Eldredge <neldredge AT hmc DOT edu>
>    Date: Mon, 1 May 2000 02:21:15 -0700 (PDT)
> 
>    An ordinary `open' would use blocking mode.
> 
> That's what I thought.  However, then what Zack suggested didn't make
> sense to me:
> 
>     > > Therefore, I'd be willing to dump the fcntl() call entirely and open
>     > > the file in blocking mode on all hosts.  Does anyone else have an
>     > > opinion?
> 
> I thought that ``open the file in blocking mode'' means you need to do
> something special, besides calling `open' or `fopen'.  If the normal
> open does that by default, as I thought it did, then nothing needs to
> be done, right?

The normal open is in blocking mode, yes, but cpp asks that it be
nonblocking (O_NONBLOCK in the second argument to open).  That has two
effects.  It means the open itself won't wait for a tape, and it means
all future reads won't wait either.  We don't want the second one -
there are sensible situations, such as reading cpp's primary input
from a pipe, where cpp needs to block in read.

The purpose of the fcntl() is to turn that off again.  If it won't
work, we must revert to the normal open.

>     > Shouldn't people who do this get what they were asking for?  I mean,
>     > if someone *really* wanted the preprocessor to read the tape,
>     > shouldn't the preprocessor get stuck if there's no tape?
> 
>    Perhaps.  The more obvious behavior would be to complain that
>    /dev/rmt0 has some problem, and abort.
> 
> Why abort?  Perhaps the user is just inserting the tape.  Why isn't
> waiting for the tape (a.k.a. ``wedge'') the right thing to do?

On some systems, a process stuck waiting for a tape is unkillable.

>    Yes, blocking/non-blocking has no effect when dealing with regular
>    files.
> 
> So perhaps limiting that fcntl call to devices is a better solution to
> this problem.  Since the DJGPP port cannot read block devices
> directly, it will never get to call fcntl in the case of a tape.

I would have to stat the file by name in order to know if it were a
device (of any variety) without opening it first.  That's slow, and
has a race condition.

>    #include </dev/zero> will usually make
>    the compiler or preprocessor slowly eat up all memory, and then die.
>    This can make for a nice denial of service, especially if the system
>    will kill other processes when memory gets low (Linux can).

I'd be delighted to know how to tell /dev/zero from /dev/null without
memorizing device numbers.  The reason I said we'd get stuck anyway is
that we permit all possible _character_ devices as input, and
/dev/rmt? are character devices, not block.  So is /dev/zero, and
/dev/mem, and a whole pile of other things that the preprocessor
shouldn't touch... but also ttys and /dev/null, which are reasonable
things to feed to the preprocessor.

On the other hand, any DoS attack you can perpetrate with cpp and
/dev/whatever, you can do just as well with sort.  (cat doesn't try to
read the file in all at once.)  The Unix Way (tm) is to assume that
the user has a good reason for whatever they did - trying to divine
which character devices are "safe" isn't the style.

zw