OpenInv

Bukkit Plugins
4M Downloads

the (literally limitless) "* true" permission cannot be overridden

LaurenceBarnes opened this issue ยท 3 comments

commented

As the title says, it is a permission logic issue. If a permission group that has "* true" (which basically sets all possible permissions to true) is assigned to the player, and the same player has an additional higher weight group that negates some specific permissions which are annoying if set to true, OpenInv permissions are not properly negated, as it appears.

I found that out with an interaction between CraftBook 3 and OpenInv. If "silentcontainer" is activated, CraftBook Pipe signs cannot be placed on proper pipes and give the player trying to place them "area.use-permission" as an output. OPs seem to have it active by default, but can manually deactivate it and then place CB signs as normal. Players however that have the "* true" permission (and OP), cannot place any signs regardless of whether they deactivate silentcontainer or not. Denying the openinv.silent and openinv.silent.default permissions through a higher weight group also does not work, as described in the first parapgraph.

The only workaround as for now is to not use "*" at all, but in some situations, it is easier to use that and deny the few other permissions through a higher weight group, than to allow individual nodes for every possible command. Ideally both options should be possible, as it allows for more flexibility in permissions management, regardless of what good practice is in certain scenarios. It is not the first time I encountered this type of issue, but it always seemed to be something that is fixable.

This was encountered with LuckPerms 5.4.15, Purpur-1603, OpenInv 4.1.10, CraftBook 3 4754

If you need more information, I'll provide it of course! Thanks in advance!

commented

Please reproduce with only OI and LP installed - not only does OI respect explicitly set state of nodes, OI also explicitly does not support wildcards for the nodes OpenInv.silent.default and OpenInv.any.default. It's much more likely (based on the fact that LP doesn't support wildcards last I knew) that you have some poor substitute for a wildcard system installed that is breaking your permissions.

For reference, here's how OI's permission node search works:

OpenInv/plugin/src/main/java/com/lishid/openinv/util/Permissions.java

Lines 53 to 76 in 3103e88

public boolean hasPermission(Permissible permissible) {
boolean hasPermission = permissible.hasPermission(permission);
if (uninheritable || hasPermission || permissible.isPermissionSet(permission)) {
return hasPermission;
}
StringBuilder permissionDestroyer = new StringBuilder(permission);
for (int lastPeriod = permissionDestroyer.lastIndexOf("."); lastPeriod > 0;
lastPeriod = permissionDestroyer.lastIndexOf(".")) {
permissionDestroyer.delete(lastPeriod + 1, permissionDestroyer.length()).append('*');
hasPermission = permissible.hasPermission(permissionDestroyer.toString());
if (hasPermission || permissible.isPermissionSet(permissionDestroyer.toString())) {
return hasPermission;
}
permissionDestroyer.delete(lastPeriod, permissionDestroyer.length());
}
return permissible.hasPermission("*");
}

For most permissions, OI starts with the full node (i.e. OpenInv.silent). If that reports as false and unset, OI deconstructs the node to the most recent period (OpenInv.) and then appends an asterisk (OpenInv.*). That node goes through the same check until finally reaching the single asterisk wildcard node. On top of that (correct search order, respecting set state), these special permissions explicitly only check their own node - the flag uninheritable is set true for both default nodes, so they do not support addition by wildcard at all.

commented

Found time to look into this - I cannot reproduce.

> lp user Adam permission check OpenInv.silent.default
[11:19:31 INFO]: [LP] Permission information for OpenInv.silent.default:
[11:19:31 INFO]: [LP] - adam has OpenInv.silent.default set to false in context global.
[11:19:31 INFO]: [LP] - adam does not inherit OpenInv.silent.default.
[11:19:31 INFO]: [LP] - adam has * set to true in context global.
[11:19:31 INFO]: [LP]
[11:19:31 INFO]: [LP] Permission check for OpenInv.silent.default:
[11:19:31 INFO]: [LP]     Result: false
[11:19:31 INFO]: [LP]     Processor: common.DirectProcessor
[11:19:31 INFO]: [LP]     Cause: 40028b1a-b4d7-4feb-8f66-3b82511ecdd6 has OpenInv.silent.default set to false in context global
[11:19:31 INFO]: [LP]     Context: (dimension-type=overworld) (gamemode=creative) (world=world)

When opening chests, SilentContainer does not enable unless it has explicitly been toggled on.
image

Note that toggle state is saved. If you leave SilentContainer on, it will still be on!

commented

well I was on a week of vacation and did not find the time to provide a bit more details before that, but I am going to attempt to reproduce that on a test server as soon as I can. I apologize for the inconvenience.