nextcloud / nextcloud/spreed

Limit matterbridge ability to ddos server ;-)

Open
#4,098 6 comments 0 reactions 1 assignee View on GitHub

@julien-nc is already working on this.

Since Sep 4, 2020.

enhancement feature: integration 📦
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.