[Suggest] "/opsudo" commands
playbabe opened this issue · 10 comments
"/opsudo <command [args]>" work 100% like /sudo but give that player permissions override to execute any commands.
since above 1.13 version /execute only can use vanilla command, so we need a new commands to do that.
(I send tricket to mojong but they refuse to edit the command)
(I also send tricket to spigot but they have no idea how to fix that)
This could be modified to not add a new command, but add a "force" flag in the command.
Example: /sudo -f untuned fix all
New command help message: /sudo [-f] <player> <command [args]> (or something similar)
the only way this could be done is if the player is temporarily granted that permission then quickly revoked as fast as the command is executed so they don't abuse it
Not sure how secure this would be, but as notshibe mentioned, the only way is probably to temporarily grant full permissions.
Bukkit.dispatchCommand(Bukkit.getConsoleSender(), send); wold work, no?
No it would not, because that would be executing the command in the context of the console sender, not the player. Any command that requires a player as the target would fail.
Bukkit.dispatchCommand(Bukkit.getConsoleSender(), send); wold work, no?
No it would not, because that would be executing the command in the context of the console sender, not the player. Any command that requires a player as the target would fail.
It depends on the context of the command they want to be issued.
You could easily use commands like /heal and any command that you can reference the player in?
Not a complete solution, either that or as previously stated could ad a force boolean check to the entire essentials command structure that allows bypass of perms. But this would only work for essentials commands.
I think you just answered yourself there. Yes, it depends on the command, and I don't think hard coding behaviours for existing and new commands would be desired to any capacity. For example, /tppos <x> <y> <z> has no player argument, but requires a player as the command sender. A console sender is no good here.
Currently how /sudo works is that it actually executes the command as the player through Player::chat(String) in the Bukkit API. This would need to do the same, but with elevated permissions. It should work for any command, not just Essentials commands.
The problem with this is that we have to either grant players full permissions through their permissions plugin or try and be smart to figure out which permissions they should receive. The former could have a lot of unintended side effects, potentially granting them perms that affect other tasks running in other threads, as well as potentially resetting the cache for their calculated permissions depending on perms plugin. The latter is pretty much impossible, because we can only guess what perms a command needs from what plugin authors define in plugin.yml under that command, which often doesn't cover all of the permissions needed to run every possible branch of the command, meaning users would be faced with unpredictable behaviour. While I can see the use of this, it's complex to do correctly and I can't see that we'd be willing to spend much time implementing this.
Closing, since it's pretty evident that this isn't feasible to do. For anyone who wants to do this manually, you can op the player temporarily, and then sudo them. Might not sound ideal, but this is exactly what Essentials would have to do to support this (which it won't, because this is hacky behavior).