Limit matterbridge ability to ddos server ;-)
@julien-nc is already working on this.
Since Sep 4, 2020.
- Dominant language
- PHP
- Stars
- 2.2k
- Forks
- 587
- Avg merge
- 18h 27m
- Merged PRs (30d)
- 333
Description
As each user can create an unlimited number of rooms and set up an unlimited number of matter bridges, there's a risk of the server getting overwhelmed.
We see three possible solutions:
- Use cgroups to limit memory and CPU usage of each matter bridge
- Use nice to lower the prio of the matterbridges
- Limit the number of matter bridges per user
cgroups
The first is very hard to configure as it depends a lot on the server in question (how many users, how much CPU is available etc) - a default setup might be unworkable on a Pi and still totally let users blow up the server on a large instance. Plus, it is very hard to limit this per user as the user starts bridges one by one - so if you want to have, say, only 1% cpu usage max per user, what cgroup settings do you give the 1st bridge? And the second?
use nice
Nice does not limit the amount of cpu usage, but would make it harder for each bridge to hurt the system's responsiveness. It can still run out of memory, however, and depending on the scheduler, the impact is still possibly non-zero.
-> Done in #4120
limit per user
The main downside of this is that matter bridges could misbehave and perhaps, based on settings, some matterbridges use far more memory than others (eg set up a room with ALL possible connections, that each have high traffic -> maybe 5 of those already take a server down..)
so what to do?
I think the easiest is to go the 'limit per user' route, but combine it with nice. So nice all matter bridge processes to the minimum - this at least decreases the risk of issues. I would, in addition, also use cgroups by default if we could come up with a configuration setting that works across the full range of systems Nextcloud supports - from a pi to a huge cluster. Maybe just a memory limitation of, say, 50 mb? That would make the use of matterbridge quite safe even with some malicious users on the system.
If we have a configurable limit of 10 matter bridges/user by default, with all matter bridges niced to 19, and a c-group limit of 50 mb, than a single user can at most use 500mb ram and, at most, hurt OTHER low-nice processes (as in, the other matter bridges). That would be bad-ish, but not allow a user to take down a system.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.