[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: and _PC_PIPE_BUF..
From: |
Robert Millan |
Subject: |
Re: and _PC_PIPE_BUF.. |
Date: |
Sun, 27 Apr 2003 01:50:44 +0200 |
User-agent: |
Mutt/1.5.4i |
On Thu, Apr 24, 2003 at 10:06:05AM +0200, Niels Möller wrote:
>
> To me, the code looks utterly broken. What is the allocated size for
> pk?
I'd say that pk is initialised without allocation, but I'm not sure, the
pk declaration is a bit confusing.
> If PIPE_BUF is larger than that size, and the other end of the
> pipe writes lots of data, you will get a buffer overflow, and
> depending on context, that can turn out to be a security hole big
> enough to drive a truck through it. The size argument to read must
> *never* be larger than the size of the buffer passed to read.
true.. then the code is wrong unless PIPE_BUF is used in the pk
declaration, which doesn't seem to be the case.
> Furthermore, I'm not sure what the code tries to use PIPE_BUF for. The
> only use of PIPE_BUF I have seen is when *writing* to a pipe, where
> you have a single process reading the pipe and multiple processes
> writing to it. Using PIPE_BUF when reading sounds like something that
> might make sense if you have a single writer and multiple readers on a
> pipe. Does gs do that? Such pipe usage seems pretty obscure to me.
that code is from a network printer driver in gs. i think it wants to
recieve a single network packet and store it in pk.
> or, if it really depends on PIPE_BUF semantics,
>
> long int pipe_buf;
> #if PIPE_BUF
> pipe_buf = PIPE_BUF;
> #else
> pipe_buf = fpathconf(fd, _PC_PIPE_BUF);
> #endif
> if (pipe_buf < sizeof(*pk))
> /* pipe_buf too small (or not existing), so we fail */
> return -1;
> else
> return read(fd, pk, sizeof(*pk))
i guess you mean read(fd, pk, pipe_buf) here. if that's what
the code pretends, this looks like a sane solution then.
> And at last, the "-1" part of "PIPE_BUF - 1" also seems strange. The
> special PIPE_BUF semantics happen for request of size up to *or equal*
> to PIPE_BUF. Quoting the glibc manual:
it could be part of the protocol. maybe the server adds a useless
byte at the end of every packet.
> Sorry if this isn't of much help, but I don't understand how that code
> is supposed to work.
even after reading the source, it pretty much confuses me.
could you have a look at it? it's in [gs]/src/gdevhpij.c
--
Robert Millan
make: *** No rule to make target `war'. Stop.
Another world is possible - Just say no to genocide