Hi!
Why not limit maximum size of the data to be uploaded? This should be
an easy patch to mod_fcgi. And about buffering, it would be more safe
to have temporary files. However, this might get insecure, if the
server has multiuser environment. E.g. other users might easily steal
those files. So, it seems that there simply is no ultimate solution.
So, to sum up, directive for limiting maximum upload would be great.
j.
p.s. we don't have multiuser environment, so, temporary files would
ease up life, as we are having c program as fcgid client - and that
program now creates temp files itself.
On May 8, 2007, at 5:02 PM, Gabriel Barazer wrote:
Hello,
BTW, no one other than me is worried by the security problem due to
large file uploading I described below ?
On 04/30/2007 15:21:29 +0200, Gabriel Barazer [EMAIL PROTECTED]
wrote:
Hello,
I experienced recently some problmes since a customer is doing large
file uploads with PHP (which is run by mod_fcgid, of course) : It
seems
mod_fcgid is consuming much memory when uploading a file to PHP. I
found
in the source file fcgid_bridge.c:473 the problem : as said in the
source, the entire request (stdin/post input) is loaded into memory
before sending it to the fastcgi Application Server (PHP in our
case).
Although it's a well workaround for dealing with slow clients, I
think
this is not the good behavior to implement, here are the points
highlighted :
- Uploading files is becoming a major security problem, since a
DoS can
be triggered by uploading a very large file (I experienced some
attacks
with 1/2GB over a fast connection)
- Additionnally, Video (=large) file uploading is becoming more
and more
popular, increasing the memory consumption.
- Dealing with slow clients must be done by the appliction server,
which
can take any appropriate measure (e.g. having a special queue
processing
for slow clients)
- Upload progress meter is not possible if all the input data is
buffered before sent to the fastcgi process. (see RFC1867 : File
Upload
Progress hook handler)
- Upload of large files is better handled by the fast cgi AS,
because of
various method used to store the upload data during progress (at the
application level , not the communication level that fastcgi is).
e.g.
PHP handles file upload by creating temporary files, which
location of
these can be customised by a php.ini directive. I think this task has
not to be handled by the fastcgi layer (which serves as a comm./
bridge
protocol, not a input processor)
- There is no need for the fastcgi process manager to handle and
buffer
slow clients : A FastCGI application designed to handle load can
handle
multiple connections AND the mod_fcgid process manager already does
multiple connection management with the adaptive spawning feature for
application which are not multi-tasked/threaded. (I even know fastcgi
applications which embed a process manager themselves)
What are the problems with slow clients :
- Sending input is very long, not constant : e.g. with shaped
connections : data flow is sent by peaks foloowed by no data
input for
a variable time.
- Connection is longer busy at the Apache level, but at the fastcgi
application level too (the workaround of buffering all the input
prevent
the fastcgi app from being busy buring the input loading).
How to deal with this, my proposal :
- What about buffering input like the output buffer, by chunks of,
say,
8Kbytes ? The major problem is the time to fill the buffer : if
the time
required to fill the buffer is too long, application can timeout,
but I
think this is the normal behavior of an application to manage
communication timeout. What about don't buffering the input at all ?
This way the data flow AND the data flow rate can by processed by the
application (such as measuring the data flow rate to put a slow
request
in a special queue).
- Because maybe some users prefer the current behavior of
buffering all
the input data, a compatibility switch would be a nice thing (e.g.
InputBuffering Off / On)
What do you think about it ?
BTW: who are the current maintainer(s) of this project ? The
documentation of this project is not very up-to-date and I had to
read
the source code to know all the directives... Maybe can I be of
some help ?
Regards,
Gabriel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
--
---
This SF.net email
