Graham Dumpleton wrote:
Can you explain more how it would be a security problem?
I doubt it would really be much of a problem, I'm just guessing at
obscure things that could break. An example would be something like...
- Malicious client sends chunked request to server that doesn't expect it.
- Server passes request.clength to its custom C module.
- I don't know what clength is when the content-length is unspecified,
but let's say it's zero.
- The C module mallocs clength (= zero) bytes.
- Server calls request.read(), and passes the data block to the C module.
- C module appends the block to its buffer, causing a buffer-overrun.
I don't really think it's the responsibility of mod_python to protect
users from this, and as I mentioned before I suspect this type of attack
may already be possible even without chunked requests. I'm just saying
it's the only type of example I can think of that would be broken by
making the default "dechunk" rather than "error on chunked request", so
I don't think making the default "dechunk" should be a problem.
I thought someone already submitted a patch because read(len) used to return
< len bytes in the past, and it was considered to be breaking the file-like
object API.
Never been the case with mod_python that I know of.
Just dug it up again:
http://www.modpython.org/pipermail/mod_python/2000-August/011329.html
Obviously this patch was accepted long ago. I guess it doesn't really
matter as long as we don't change the behaviour of read() in blocking mode.
And if you restrict it to returning either len bytes or a "would block"
exception, it would not solve the original problem I was intending to solve
- having to process and respond to < len bytes from the client before the
client will send any more.
Yes it would. When blocking turned off, the intention would be that
read() with or without arguments would always return only what it
found. The returning of flag to indicate it would block, would only
occur if not data at all available. Thus, disabling blocking would
make it behave like a non blocking socket.
I was addressing the possible design where read() was not permitted to
return partial data, ever. OK, if you give me nonblocking reads and
partial reads when I set a "nonblocking" flag, that will solve my
problem and I will be fine. And non-blocking mode is certainly a very
useful feature. But I still think they are two independent features. In
my application, I just want to ensure I have processed and responded to
all client data that is available in the buffer, otherwise the client
may hang waiting for the response and therefore send no more data to the
server, yielding deadlock. And I would actually prefer the read to block
- if you attach both the "nonblocking" and "partial read" feature to the
"nonblocking" API flag, it is an incovenience for me since I'm just
going to have to sleep and read again whenever I get a "would block"
return. Yes, this is a minor inconvenience, but I believe this
demonstrates that we are talking about two different features here, and
that it is useful to enable partial reads without enabling non-blocking
mode.
Rather than an exception, the other option is to return None instead.
Thus, returning empty string means end of input, and returning None
means would block.
Ah, yes, I like idea of None a lot. Especially since this is not really
an exceptional condition - in fact one might expect that a "would block"
return would be more common than actually returning data. I think it is
a good general principle that normal behaviour should not be represented
with exceptions.
If I get some time I might be able to try implementing nonblocking mode
and/or timeouts, but I have no idea what the Apache API for this is.
Could you point me at the API I would need to use?
Alex
