Moderator permission level

[Mylon]

I would like the ability to set users as moderators, with the power to /kick and /ban, but no other special permissions (no /command access, no /permissions access).

Unfortunately the permission system does not have a permission to prevent /command access so anyone promoted to /admin, if they can chat, can also simply /command their way to bypass the permission system. Permissions also cannot restrict /config set to turn commands back on so that doesn't work either.

[Hornwitser]

In 0.17.66 you still have to be admin to do (an unspecified list of) admin like things when the fine grained permission system would do a much better job at this. Permission (at least in 0.17.66) can restrict /config via the "Change multiplayer config" option, but this doesn't help as you can still trivially bypass all the permissions if you can run lua commands. There's no "run command" permission it's combined with chat in the "Write console" permission (having moderators that can't chat is needless to say not an option.) Turning off lua commands is not an option either, it's got far too much use in public multiplayer games.

So there's still no option to have a Moderator level permission without them being able to trivially bypass all permissions as they must be server admin to do anything useful, running lua commands is too useful for the admins to disable and you can't prevent Moderators from also being able to run lua commands without gagging them completely.

[Rseding91]

I'm not against making different permission levels for admins but I haven't seen any good proposals about what amount and kind of levels should exist.

If the levels should be hard-coded or dynamic. Maybe dynamic with some default ones that can be changed?

[Hornwitser]

Why would you hardcode the permissions for multiplayer moderration when /permissions exist? Add permissions for kick, ban, whitelist, promote, open other player gui, swap player, lua command, etc, and let the multiplayer admins decide (but there really need to be categories to the edit permissions panel, or it'll be impossible to find the relevant permissions quickly.)

[Koub]

A GUI allowing to create a custom role with checkboxes for each privilege would probably be mostly convenient.

Something like this for example

2019-08-22 14_28_31-Content Server - Autorisations.jpg (138.73 KiB) Viewed 4131 times

[Rseding91]

The permissions GUI is specifically built around input actions. All of kicking, banning, and those actions are done through the "write to console" input action so there's nothing to configure in the permissions GUI.

Any fine-grain admin levels would be outside of that system although could still be done through the permissions GUI some how.

[Hornwitser]

So. If you select ban through /admin does that sends a write console input action with the content "/ban playername" to the server? Seems a little rube goldberg to me. Why can't you consider ban/kick/mute/lua command/chat etc to be separate input actions? It would avoid having to write another permission system.

[slippycheeze]

Sounds like something that a mod could implement, to prove the concept and prototype a decent UI or whatever for it, and then demonstrate how it'd work in practice, backed by real experience with it.

[Hornwitser]

So @Koub and @slippycheeze a UI and concept like what /permissions already is?

A.png (261.98 KiB) Viewed 4098 times

[Rseding91]

So. If you select ban through /admin does that sends a write console input action with the content "/ban playername" to the server? Seems a little rube goldberg to me. Why can't you consider ban/kick/mute/lua command/chat etc to be separate input actions? It would avoid having to write another permission system.

No, the GUI logic in /admin is its own input action with flags to say what it's actually doing internally.

The reason "write to console" is 1 action is because that's all you're doing. You're entering text into the console and you hit enter. That takes the text and sends "write to console (text)" as an action to the game. Once the game gets the action it parses the text to figure out what it's actually supposed to do with it.

The reason it works that way is: input action count is limited to 255 total. We're currently using 221 of those values for game things. If we took everything which can be done through "write to console" and split it out before sending it into the game as an input action that would increase by 45 (the number of distinct things which can be done as /*text*) - above the maximum we can support without changing the input action ID value and making every input action bigger as a result.

[Hornwitser]

Unless I'm missing some core thing with input actions extending the id past 255 wouldn't make every action bigger. You already have variable length encoding of numeric fields in your protocol (and I presume in the save as well) where values from 0-254 is one byte and >254 is encoded as 3 or 5 bytes depending on the size of the field. As long as the common actions have IDs below 255 the ID still take up one byte.

[Rseding91]

Unless I'm missing some core thing with input actions extending the id past 255 wouldn't make every action bigger. You already have variable length encoding of numeric fields in your protocol (and I presume in the save as well) where values from 0-254 is one byte and >254 is encoded as 3 or 5 bytes depending on the size of the field. As long as the common actions have IDs below 255 the ID still take up one byte.

We do, but that's not the only concern. Console commands are done once it enters the game state. To change that would mean re-writing the entire console command processor and that's just not something any of us want to do. It works very nicely as it is now.

Making a admin permission levels system outside of the input action system makes far more sense to me than trying to slice up the existing game logic around console commands.

Because it still wouldn't handle the fact there are 3 ways to ban someone: /ban in the console, /admin + click ban, and /c game.ban_player(...)

Making /ban be its own input action doesn't make the other 2 respect if the person has the permissions to do that input action.

And finally: the "input action permissions" was built as a quick and easy way to filter input actions. It was never and probably never will be the end all permissions system. It will always need side systems to handle the more fine-grain details of what each action can do.

For example: you may want to allow someone to use deconstruction planners but only on things they personally built - that will never work in the input action level.

[Hornwitser]

Preventing a lua commands invoked from a player from banning a player sounds far more difficult than worth anyone's time to solve. Consider for example /c script.on_nth_tick(50, function() game.ban_player(...) end). So in my mind being able to execute lua code means being able to bypass all permissions checks.

I don't really see the obstacles you see with using input actions as a permission system. If /ban was it's own input action, then /admin + ban really ought to be using it and /c <arbitrary lua code> isn't of any concern. Yes, rewriting the command processor would suck, and so would probably extending input actions ids. But does it really suck more than writing another permission system? I guess that's for you to decide.

Ultimately what we in this thread want is a way to give someone access to /kick and /ban without giving them access to dangerous things like /command. Being able to prevent players from decon planning other players builds sound cool and all, but this level of control is not really what's asked for.

If there's anything extra I would like to see it would be the ability to add custom permissions to the permissions gui and a good description of what each of the existing permissions does.

[Mylon]

How about instead of doing this via the permission system (which seems ill-suited to the task), this was done via a hardcoded moderator role? /kick and /ban commands would check for admin or moderator role, rather than just admin role.

In reference to my original request, I noticed when building a votekick system that if I call game.ban_player from within the add_command() function, the script call fails silently because the player calling for the vote does not have sufficient permissions!

Griefers are a serious problem and I'd like more options of dealing with them, like giving moderator powers to regular users. I can probably work around and make votekicking work by checking on_nth_tick check and going over the list of to-be-banned players, but that seems like an unnecessary extra step.

Alternatively, as Hornwitser noted, having command access makes all other permissions redundant. Therefore it would make more sense for /kick or /ban to check user permissions than to check for admin status.

[hidden_relic]

Just a thought, and it may be a little too..."picky", but perhaps a sort-of 'points system' could work, for the (hopefully never occurring) possibility of your newly recruited 'moderator' having the permission to kick/ban any of the other moderators/admins. Forgive me if there is already something in place to stop admin from kickbanning other admins, I've been lucky and haven't had to use either command, but it seems to me a 'standard' player could have a set of default permissions that could be adjusted in server-settings or server-adminlist.json if one wished to tweak their world, and permissions could be added on to trusted users by an admin, with a point-value added to the promoted player with each permission granted.
For example, I started playing this server as a standard user, with 0 points. I have been putting a lot of work into this server, the admin has granted me the ability to use deconstruction planner (10 points), lay down blueprints (5 points), edit circuit conditions in combinators (10 points), and has given me the right to kick players (30 points). Another player has been promoted, with all the same permissions, but admittedly aren't savvy with circuit conditions so weren't granted the ability just yet. I believe this other player shouldn't be able to remove me from the game, as I've been trusted with 10 more I'm-a-good-boy dollars.