help-hurd
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]