Factorio Forums

Certain script action like game.kick_player requires the execution context to be a player that is promoted to admin. This makes absolutely no sense as the only way you can execute game.kick_player() is if you have permission to run commands, or if you clicked on a custom script GUI which does it for you.

If you can run commands you can trivially bypass the admin requirement by registering an on_nth_tick event handler and do the kick_player action there as the on_nth_tick event handlers are executed with the server as the context. If you can run commands you can also do things like lock up the server with an infinite loop, delete the world, set yourself to cheat mode, unlock all tech, set spawn to far into biter territory and kill everyone. It's basically unrestricted access to the game, far far more powerful than the things admin promotion let you do.

And if a custom script GUI gives you a button that invokes game.kick_player() isn't it kind of obvious that the intention here is to kick the player? This would be exactly how you'd implement a custom moderator interface that doesn't require admin promotion.

Thanks for the report however it's either this or revoke the ability for mods to use any of these commands.

As it is now, don't allow players to run Lua commands. Or, only allow admins to do it.

Allowing Lua commands bypasses all of the permissions system because the Lua API allows you to do virtually everything outside of permissions.

Are you saying you can't make game.kick_player kick the player regardless of how it's run? That seems strange. Having the option to let everyone run commands also seems a little strange if you consider it above admin.

Hornwitser wrote: Tue Nov 12, 2019 5:06 pm Are you saying you can't make game.kick_player kick the player regardless of how it's run? That seems strange. Having the option to let everyone run commands also seems a little strange if you consider it above admin.

I could do that but that's not a real fix. That's like saying "if someone can watch me type in my password and know it, then I might as well just not have a password".

Also, runtime subscribing to events - especially in multiplayer - is a sure way to trigger desyncs. If anything, it might make sense to prevent that.

There's nothing wrong with run time subscription of events so long as you keep track of which events you have subscribed to and make sure the same events are subscribed to in on_load. You would be removing a useful feature if you prevented this.

As for the admin check I really, really don't understand your view point here. What is the purpose of preventing game.kick_player from working when the current execution context is a player without admin rights? If you made game.kick_player work in all cases, then it wouldn't change much at all. Scripts and player commands can already bypass the existing check with an on_tick handler.

Trying to sandbox it such that these actions require the player initiating them to be an admin sounds both nuts and futile.