LuckPerms dev 362

With a group that has a '*' wildcard to inherit all permissions by default, LuckPerms does not seem to be granting all plugin loaded and bukkit permissions.

/lp user <user> setprimarygroup Senior-Admin
Player tries to use the command /tps.
Player does not have permission to use the command despite having a wildcard inheritance '*' from the group Admin - which Senior-Admin inherits.
/lp verbose on returns bukkit.command.tps false.

Player tries to use the worldedit command //wand.
Player does not have permission to use the command despite having a wildcard inheritance worldedit.* from the group Senior-Admin.
/lp verbose on returns worldedit.wand false.

With PEX.

/pex user <user> group set Senior-Admin
Player tries to use the command /tps.
Command works and returns the server tps.
/pex toggle debug - console returns [PermissionsEx] User mibby checked for permission 'bukkit.command.tps', regex-matched a value of true from cache.

Player tries to use the worldedit command //wand.
Command works and provides a worldedit wand.
/pex toggle debug - console returns [PermissionsEx] User mibby checked for permission 'worldedit.wand', regex-matched a value of true from worldedit.* (CACHE MISS)

Server copy for testing. PermissionsEx plugin is in the PermissionsEx directory.
https://www.dropbox.com/s/xggdu3pnxjbgpev/server.zip?dl=0

# If the plugin should apply wildcard permissions.
# If set to true, LuckPerms will detect wildcard permissions, and resolve & apply all registered
# permissions matching the wildcard.
apply-wildcards: true

# If the plugin should parse regex permissions.
# If set to true, LuckPerms will detect regex permissions, marked with "r=" at the start of the
# node, and resolve & apply all registered permissions matching the regex.
apply-regex: true

# If the plugin should complete and apply shorthand permissions.
# If set to true, LuckPerms will detect and expand shorthand node patterns.
apply-shorthand: true

# If the plugin should apply Bukkit child permissions.
# Plugin authors can define custom permissions structures for their plugin, which will be resolved
# and used by LuckPerms if this setting is enabled.
apply-bukkit-child-permissions: true

# If the plugin should apply Bukkit default permissions.
# Plugin authors can define permissions which should be given to all users by default, or setup
# permissions which should/shouldn't be given to opped players.
# If this option is set to false, LuckPerms will ignore these defaults.
apply-bukkit-default-permissions: true

# If the plugin should apply attachment permissions.
# Other plugins on the server are able to add their own "permission attachments" to players. This
# allows them to grant players additional permissions which last until the end of the session, or
# until they're removed. If this option is set to false, LuckPerms will not include these attachment
# permissions when considering if a player should have access to a certain permission.
apply-bukkit-attachment-permissions: true

Yeah, i noticed that too

First of all: Stop comparing things of LuckPerms with PEX.
And next: There are many reasons, why this maybe won't work.

1. The permission is not default for OPs
2. You need to change the world/server, that permissions update (That's the case for Luckperms.autoop)

@mibby The behavior you are experiencing is in fact intentional. You have the specific permissions set to false in previous groups.

Let me give you an example:

Let's suppose you have 2 groups: A, B (inherits from A)

When you set the permission * in B, everyone in the group has all permissions.
But now when you set test.test to false in A, it is false in B too! This is intentional behavior! To work around that simply give A explicit permissions to test.test.

I case you are curious as to why that's the way it is, it is because LP first checks explicit permissions, before wildcard permissions are checked. This is that way because it vastly improves performance.

See https://github.com/lucko/LuckPerms/wiki/Advanced-Setup#permission-calculation for more details.

Non wildcard/regex permissions will be overridden by normal permissions

To summarise what @BrainStone said in relation to your scenario:

Although SeniorAdmin has a * permission set, it most likely inherits the negated bukkit.command.tps command from your default group, which takes priority over the wildcard.

Three key facts:

1. Non-wildcard permissions will be considered before wildcards
2. More specific wildcards (for example worldguard.*) will be considered before less specific wildcards (for example *)
3. Inheritance is fully resolved before wildcards are considered.

This is how LuckPerms is by design. I'm indifferent about which design is better (whether inheritance should be considered after wildcards vs how it is now), however, the current approach is significantly faster, which is why I opted for it.

It's not currently viable to maintain a toggle between these behaviours. You can just override negations higher up the inheritance tree to obtain the behaviour you desire.

@Andre601 I believe it is perfectly acceptable to compare LuckPerms to PEX since that is what most people would be coming from. If the comparison chart is suppose to show that LuckPerms is the overall better permissions plugin to use, behavior should function similarly without issues when migrating from another permissions plugin, otherwise people will assume the plugin is broken when commands don't work. As far as I remember when testing, most permission plugins followed the same general behavior regarding inheritance.

@lucko

Although SeniorAdmin has a * permission set, it most likely inherits the negated bukkit.command.tps command from your default group, which takes priority over the wildcard.

Except no groups inherits from default. Even removing the negation from default, I still can't use the command. However looking further into it, it seems to be due to the inherited negation from the member group.

You can just override negations higher up the inheritance tree to obtain the behaviour you desire.

That's what I thought behavior would be like. As I negate all worldedit perms in the Admin group but provide them in the Senior-Admin group with the worldedit.* flag. Senior-Admin group should have a higher priority and override the negation in Admin, but this is not the case.

What seems to be the issue is the negation of this permission in the admin group.

- fawe.permpack.basic:
    value: false

It is a group of permissions set in the plugin.yml of FastAsyncWorldEdit which just provide a list of worldedit permissions. Inheriting the worldedit.* permission in the Senior-Admin group doesn't seem to override the negations and re-inherit them.

Thus two questions.

1. What kind of performance difference is there when allowing the '*' wildcard to inherit all permissions (including plugin.yml false set permissions) by default and override any negation down lower in the inheritance tree? Since that behavior is what people are familiar with when using a global wildcard to override all.

With PEX, the * wildcard forced inheritance of all permissions again if they were negated earlier in group inheritance unless they were specifically negated again in the same group above the wildcard. For example, a plugin may provide permissions to everyone by default, which you may not like, so you negate it for members. But you want admins to still be able to use the command, so you give admins a global wildcard flag to have access to everything. There is still a command you wouldn't want admins to have, so you also re-negate it in the same group before the wildcard. For example if you didn't want admins to have worldedit from the * wildcard.

2. Similarly to above, is there much of a performance impact to allow plugin wildcard inheritance (i.e. worldedit.*) to override earlier negation from a lower group in the tree?

That's what I thought behavior would be like. As I negate all worldedit perms in the Admin group but provide them in the Senior-Admin group with the worldedit.* flag. Senior-Admin group should have a higher priority and override the negation in Admin, but this is not the case.

What seems to be the issue is the negation of this permission in the admin group.

• fawe.permpack.basic:
  value: false

Quote from @lucko

Three key facts:

1. Non-wildcard permissions will be considered before wildcards
2. More specific wildcards (for example worldguard.*) will be considered before less specific wildcards (for example *)
3. Inheritance is fully resolved before wildcards are considered.

In your case it's because fawe.permpack.basic does not have any wildcarts and because of that, does override any worldedit-permissions, because you're using wildcarts there.
Just set the fawe-permission to true for your senior-admin-group and it should work fine.

I believe it is perfectly acceptable to compare LuckPerms to PEX

Agree - but it's silly to assume that it would function in exactly the same way. If LuckPerms worked in the same way as PEX, it would be just that: exactly the same. That has never been my aim with this project.

behavior should function similarly without issues when migrating from another permissions plugin, otherwise people will assume the plugin is broken when commands don't work.

As stated on the Migration wiki page:

LuckPerms has some similarities with other permission plugins, however, some parts are fundamentally different, and therefore sometimes automatic migration is tricky.

The migration does a pretty damn good job of accurately replicating setups, especially considering the complexity of the plugins it pulls data from.

As far as I remember when testing, most permission plugins followed the same general behavior regarding inheritance.

Yes I agree, but the point you are arguing here is an intricacy, and not general behaviour.]

Except no groups inherits from default. Even removing the negation from default, I still can't use the command. However looking further into it, it seems to be due to the inherited negation from the member group.

That was my point, swap "default" with "member" in my comment - it applies in the same way.

It is a group of permissions set in the plugin.yml of FastAsyncWorldEdit which just provide a list of worldedit permissions. Inheriting the worldedit.* permission in the Senior-Admin group doesn't seem to override the negations and re-inherit them.

Yes, I imagine that's exactly what it is. The reason you're experiencing this is because child permissions are processed before wildcards. As Andre said, you can just set the permpack permission to true to override it higher up.

What kind of performance difference is there when allowing the '*' wildcard to inherit all permissions (including plugin.yml false set permissions) by default and override any negation down lower in the inheritance tree? Since that behavior is what people are familiar with when using a global wildcard to override all.

By implementing the current inheritance design, the plugin is able to completely flatten the inheritance tree when setting up a user. This is the most expensive (in terms of performance) part of the permission checking process. We can do this before any permission checks have even taken place - in the case of LuckPerms, asynchronously.

Once a users permissions are flattened, they are much easier and faster to query. Child permissions, wildcards, regex permissions are then processed (in that order) at check-time, critically, after inheritance.

The alternative is on and for each permission check:

• Resolving one level of inheritance
• Checking for a direct match
• Checking for a child permission, wildcard or regex match
• Processing the next level in the same way

(this is how most other permission plugins implement inheritance + wildcards, as you point out)

I've spent the last year painstakingly optimising this process - this stuff makes a huge difference on servers with deep inheritance trees & frequent permission checks.

Similarly to above, is there much of a performance impact to allow plugin wildcard inheritance (i.e. worldedit.*) to override earlier negation from a lower group in the tree?

Same answer as above, since all wildcards are handled by the same system.

you also re-negate it in the same group before the wildcard.

As I mentioned earlier, this is super messy when you want to store your data in SQL - order fundamentally does not matter in LP, and that's not going to change.

I hope my reply doesn't come across as dismissive or rude - I appreciate your comments. However, I've spent a long time developing and improving this system, and wholeheartedly believe it to be superior.