search

blue-nebula / base

Main repository of Blue Nebula, a fast-paced shooter with a unique parkour system. It is a fork of Red Eclipse and is free software.
https://blue-nebula.org
15 stars 6 forks source link

"Cap" the global auth system rights #144

Open ghost opened 4 years ago

ghost commented 4 years ago

Right now, global authentification system can alter way too much without local admin being able to block access to sensible stuff, that may result in security concerns. For example, it would be possible to overload memory or disk by changing how demorecords are managed.

I think the global moderators should not, by default, be allowed to alter a server's gameplay or other variables. Ideally, global auth system should be considered a "guest", the local admin should be able to reject some levels of rights. One could only accept auth as known users, another would accept up to moderators, official servers would accept all... (higher access levels would be "capped" to the maximum accepted by local configuration).

MoonPadUSer commented 4 years ago

Is there a way to lock some variables yet?

TheAssassin commented 4 years ago

that may result in security concerns

I disagree that there's any more security concerns than without the access. It's more or less annoying, at most.

I think the global moderators should not, by default, be allowed to alter a server's gameplay or other variables.

Moderators aren't. Only global admins, developers and above can touch the sensitive stuff. Operators and moderators are purely moderative, and can only alter stuff that affects the game management (e.g., time limits, team stuff, kick/ban, ...).

I think the global moderators should not, by default, be allowed to alter a server's gameplay or other variables.

That's not up for discussion until we want to really break backwards compatibility. We need to postpone this issue.

One could only accept auth as known users, another would accept up to moderators, official servers would accept all... (higher access levels would be "capped" to the maximum accepted by local configuration).

We should compile a catalog of variables (future) global roles (we are going to remove/restructure some) are going to need access to. The rest can be protected just fine. We shouldn't change servers with settings we don't like anyway. If there's violations of our community guidelines, we can still remove them from the list completely if a dialog doesn't turn out to work.

However, what should be possible is for server owners to actively opt in to (or opt out of) allowing global moderators/admins/devs to actually manage their servers. A vast majority of server owners is likely okay with this, they might even prefer that as they don't have to actively monitor their servers.

ghost commented 4 years ago

Moderators aren't. Only global admins, developers and above can touch the sensitive stuff.

Exact, thanks for the precision.

We shouldn't change servers with settings we don't like anyway. If there's violations of our community guidelines, we can still remove them from the list completely if a dialog doesn't turn out to work.

Exactly. But this relies on trust, both in the global dev/admin/moderators and in the software (if there is a security flaw somewhere in master/auth systems, one could attack registered servers). My point here is that, while having a group able to tweak variables (for official servers) is a useful feature, it should be possible to avoid that on non-official servers, only allowing the moderation system instead of the possibility of changing variables.

A vast majority of server owners is likely okay with this, they might even prefer that as they don't have to actively monitor their servers.

Indeed, and I consider this a nice option that should not be removed.