Re: Minor DJGPP fixes

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Mon, May 01, 2000 at 06:25:18AM -0400, Eli Zaretskii wrote:
>    From: Nate Eldredge <neldredge@hmc.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