1073241 - Do not load huge attachments in memory

Status: RESOLVED DUPLICATE of bug 906010

(Bugzilla :: Attachments & Requests, defect)

Description

[Damien Nozay [:dnozay]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.122 Safari/537.36

Steps to reproduce:

Here is the Attachments config:
* maxattachmentsize = 0
* maxlocalattachment = 8000 MB
IOW all the data is on disk.

1) Users can upload attachments that are fairly large (e.g. weeks worth of logs, support bundles).
2) Users can view/download attachments, e.g. https://bugzilla.example.com/attachment.cgi?id=1234


Actual results:

1) attachment.cgi loads everything in memory.
2) server slows down for a while while it is slurping the contents in memory.
3) crash.


Expected results:

Attachment should have been sent to client in a chunked fashion while keeping memory usage low.

Comment 1

[Damien Nozay [:dnozay]]

sorry - wrong component.

Comment 2

[Frédéric Buclin]

This is not a security issue. One must be crazy to allow attachments as large as 8 GB (and this value is really not common). If this becomes an issue, an admin is free to decrease maxlocalattachment.

I agree that we shouldn't load all the attachment in memory, though.

Comment 4

[Damien Nozay [:dnozay]]

(In reply to Frédéric Buclin from comment #2)
> This is not a security issue. One must be crazy to allow attachments as
> large as 8 GB (and this value is really not common). If this becomes an
> issue, an admin is free to decrease maxlocalattachment.
> 

my work involves hypervisors.
most our attachments are support bundles containing (amongst other interesting things) memory dumps.
Do you know how big a memory dump of a host with 64GB RAM is? It is 64GB uncompressed.

Comment 5

[Gervase Markham [:gerv]]

dnozay: I think this is a classic case of some people's edge use cases meaning that the code has to be more complex for everyone :-) 

If you want to write a streaming version of attachment.cgi, we'd be happy to consider your patch. But I suspect no-one on the Bugzilla team is going to write one.

Gerv