On 05/08/2007 21:41:41 +0200, Janis Volbergs <[EMAIL PROTECTED]> wrote:
> 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. > I don't think limiting the input data size is a good workaround, because FastCGI has to manage only the transport and communication between the FastCGI application server and the web server. Thus filtering/limiting/buffering has to be done by the FastCGI server, not the process manager (mod_fcgid in our case). I don't think the transport layer has anything to do other than queuing up connections, then transmitting data over sockets. Hence my proposal of completely disabling the FastCGI buffering system, or replacing it by a REAL buffering system which buffers chunks of data (8192 bytes is a good average buffer size). CGI works like this. > So, to sum up, directive for limiting maximum upload would be great. I really don't think this the right way to correct this problem, because only the application server knows what type of input data is sent, its size, and how to handle it. (at the application level, e.g. PHP knows if input data is a file by reading the Content-Type header, but this can be XML stream for SOAP/XML-RPC usage, media streams for on-the-fly encoding, and so on). This would be insane to buffer the input into a temp file if the input is a media stream for example. > 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. > And this is the right way to handle data : let the application server create temp file is his secured environment/jail/user rights, just as PHP or some other scripting langages do. Gabriel > 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 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 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 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
