Permissions based on command arguments

[Wunka]

This is a goal I had since the beginning of the permission system.
Here I want finally make an issue out of it and make this the place to discuss how that should look like.

What do I exactly mean with this?
Take for example the spawn command.
What if we wanted everyone to be able to get their spawnpoint but from no one else (and not being able to set it)

through the argparser I think we can achive this.

For example the permissionPath could be:
(whitelist)/command/spawn/playerIndex=null (allow running /spawn where playerIndex is null => the player themself
(blacklist)/command/spawn/playerIndex=null/x => disallows x parameter => you cannot set the spawnpoint (could also do /command/spawn/playerIndex=null/x/y/z but with x is shorter

We could also go by the Args union and get permissionPaths through that:
(whitelist)/command/spawn/@"/spawn <playerIndex>" (how do we set here that the player should only be able to do it for them self?) With <playerIndex=null>? or maybe we append the arguments after that like in my first example? so /command/spawn/@"/spawn <playerIndex>"/playerIndex=null?

(needs to integrate nicely with #3125 to not make different syntaxes, thats also where I took the playerIndex=null idea from)

[Argmaster]

Overall I am not to found of this idea, the main reason is that not every command needs same granularity of control resulting in either boilerplate or insufficient control. I would prefer if permission checks were done explicitly, manually and through simple API - does user have permission to do that? No? Then GTFO. Yes? Great, let's continue.
Are the paths arbitrary or hard coded?
Imo it would be best of they were arbitrary, described in command documentation.
The most glaring case of privilege granularity being critical is /sbb and /blueprint commands - they are very complicated in terms of what they can access (or will be able to access in the future). As I recently described in discord message https://discord.com/channels/443805812390100992/702167480654757991/1524022936988811424

So, I have ran into assets.zig pissing me off again. I guess after I hard resetted my last attempt on
refactoring it I am damned to revisit it.
This time I wanted to finally enable loading blueprints from assets, but that's kind of hard, even if I were to brute force it by hardcode search logic. Basically, I need to be able to re-do the proper asset search process with up to date filesystem data.
Also, I have my previous wild idea of adding more abstraction to where server/client differentiation occurs.
For requirements, just /sbb (still doesnt exist) and /blueprint suggest following inputs would be very, very important:

• absolute path
• relative path
• id
  Then there are sources:
• server global assets
• server world assets
• server cubyzDir/blueprints
  (and now it gets crazy):
• client global assets (hey i have this very cool addon that is not there on server but i want to just spawn something from my addon on server!)
• client cubyzDir/blueprints
• client cwd (hey I have this very... you get the point)
• client cross-world asset loading (hey I have this world where I work on my sbb prototypes...)
  On top of that, It would be great if I could just use the same API to write back changed assets, at first I thought I need this only for bps and sbbs but then I thought about runtime manual migrations write back (we talked about that a while back, not sure if we have an issue, please link if you remember!)
  No even mentioning I might go insane if I have to re-figure out path normalization and safety even one more time.
  Ye well Ima work on some prototype, but I suspect discord will cut that message If I try to paste code here. I will let you know if I settle on something that remotely makes sense
  Surely you love my insanity rants I post here every now and then

Each search source may in theory require different privilege, with sources possibly being grouped, resulting in less, but more than 1, privilege. To determine default source it would be best to be able to query user privileges. Command should also allow explicitly specifying sources to use, likely though flags.

What about help command? Ideally you wouldn't be able to even ask about commands you don't have access to, to reduce possible attack surface.

There are two other issues I see from design perspective:

• fragility/rigidness of automatic behavior we create that will limit what can be changed in, currently mostly unconstrained, argparse
• inherent complexity of such automated system, built on to already meta code heavy argparse

For example the permissionPath could be:
(whitelist)/command/spawn/playerIndex=null (allow running /spawn where playerIndex is null => the player themself
(blacklist)/command/spawn/playerIndex=null/x => disallows x parameter => you cannot set the spawnpoint (could also do /command/spawn/playerIndex=null/x/y/z but with x is shorter

We could also go by the Args union and get permissionPaths through that:
(whitelist)/command/spawn/@"/spawn " (how do we set here that the player should only be able to do it for them self?) With <playerIndex=null>? or maybe we append the arguments after that like in my first example? so /command/spawn/@"/spawn "/playerIndex=null?

What you are describing here imo can be summarized as "how do we string encode infinite possibilities of command arguments into a unique string". There is already a way to do this, it's called source code.
If we do find reliable patterns in permission queries we might want to build abstraction, but personally i think we are not there yet.

[Wunka]

Okay so then its just about using it in the commands, as commands can already just ask what permissions the user has.