Can you walk me thorough the kind of abuse/misuse you're seeing (or anticipating)? We have quota infrastructure and could extend it to files, but there's currently no per-user component, and I'd like to see if we can come up with better approaches to handle specific abuse scenarios since quotas are a pretty blunt instrument.

This issue stems from a conversation I had with a PI of one of the projects on which we're using Phabricator, and we're about to open the instance to a wider audience (not necessarily general public, but a wider audience nonetheless). His comment was basically, "Disable the upload button for external users." Note, here, that 'external' are still logged-in users, not "public".

I know enough about how Phab works to know that would also break useful functionality, like the ability of users to upload screenshots for bug reports.

Essentially, we're using Phab as a vehicle to distribute releases of our software in addition to its nominal role in the development process. Each release, we create a wiki page w/ release notes & "F" links to objects in the Files app that represent our binary releases. As those releases are fairly large, we have the file upload limit set fairly high (512MB). (Whether or not that's a good idea or scaleable depending on how Phab handles "File" downloads is probably another matter entirely; it's convenient that we don't have to maintain a separate download site/user list for releases.)

Most users don't have a requirement for such a high limit; an upper limit in the 10s of MBs would probably be reasonable.

I could imagine a scenario in which a malicious/compromised user could put some hurt on an instance by abusing high upload limits to fill the disk, which could have many consequences depending on what storage backend you're using, and how the filesystem is configured (if you're using the FS backend). You wouldn't even necessarily need high upload limits, just repeatedly uploading small files that have different hashes (unless there's a throttle on uploads that I'm unaware of.).

Such a situation would persist (even if it didn't hose the entire instance, it would still break useful functionality for many users) until someone I trust with shell access to the machine (T7592) noticed the situation and was able to clean up the mess.

Not precisely related, but as of a day or so ago, at HEAD, file sizes are unlimited for all users if you have at least one storage engine capable of storing 4MB chunks. The documentation has been updated and should reflect the modern state of the world:

https://secure.phabricator.com/book/phabricator/article/advanced_configuration/

This impacts you somewhat:

• The filesize limit has been removed entirely.
• Storing gigabyte-scale files in Phabricator is no longer a completely terrible idea.

Generally, I don't think single file limits are very useful in protecting against a malicious user who is trying to exhaust resources, because -- as you point out -- a user who is unable to upload a 1GB file can upload 1000 1MB files very nearly as easily. I think we would have to implement storage quotas to protect against this specific attack.

In general, though, Phabricator is vulnerable to DOS attacks (many responses require far more resources to construct than the resources an attacker must expend sending the request). We have some crude infrastructure to offer some protection against this, but it's disabled by default and not very effective in the best case (the cost to get as far as running one line of PHP code is likely higher than the cost to send a request). So a user who tries to upload 1000 1MB files and is quota'd after 250 can just send 1M requests for a Git resource or a syntax highlighted file or a huge page of tasks (or the homepage or really any page at all), and someone is going to have to SSH to the box or load balancer and IP ban them anyway. I think there's very little we can do at the application level to mitigate or prevent this meaningfully.

Quotas would solve a different abuse case: using open Phabricator installs to distribute l33t warez and pirated media files. We haven't seen any of this on this install so far, although it's possible that better support for large files could open up a new world of opportunity.

DDoS stuff

That's a fair position. Limiting malicious attackers to smaller requests, however, might run them afoul of rate limiting policies on other parts of infrastructure.

I'm a embedded engineer, so I'll trust your judgement there.

Quotas would solve a different abuse case: using open Phabricator installs to distribute l33t warez and pirated media files. We haven't seen any of this on this install so far, although it's possible that better support for large files could open up a new world of opportunity.

That was part of my motivation behind T7592; if administrators are janitors, at least give them the ability to sequester by restricting access.

I think it's reasonable to always let administrators disable files they can see. We don't run into any problems by supporting that and it makes cleanup a bit easier for a reasonable set of low-sophistication attacks / nuisance users (disable the user and then disable the l33t w4r3z they uploaded).

FWIW we have seen several users attempting to distribute l33t w4r3z via Wikimedia's instance of Phabricator. I had to set file upload limits to < 8MB in order to prevent chunked file storage.