On May 9, 2007, at 10:54 AM, Gabriel Barazer wrote:

> 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.

I understand your point, but what I proposed would be a quick and  
simple patch that would resolve the security issue.

Though, your proposal would be more logic and would give more value  
added in future.

> 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.

perhaps create a patch and propose for it's inclusion in the next  
release ;)


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.
Mod-fcgid-users mailing list

Reply via email to