WORLDGUARD-3464 - Reported by equinox

Hi,

I encountered a serious problem with the current Worldguard version (build 1592). Previous WG 6 versions are affected, too.

Please take a look to the following image which describes the problem:
http://i.imgur.com/wwuJtXj.png

There are three regions, the global region, a city (city9) and a user (zone9) region.
The corresponding flags for each region can be obtained from the image above.

Heres' the problem: The user which is a member of the city9 region, can access the chest in the zone9 region, which is an unwanted behaviour in my understanding of the region permission inheritance.
Since the zone9 region has a higher priority without any members (and only allows members to access chests), a user which is not part of that region should not be able to access the chest.

The problems get worse when the interact flag comes in, the next image shows this region configuration: http://i.imgur.com/QUU0yhM.png

The interact flag is set to allow for the global region (this works as intended). The zone region denies interaction for non-members (please note that there is an owner set), the city region does the same, but there is no owner or member.
When the user d1rty (me again) tries to open the trapped chest in both zone8 and city8 regions, WorldGuard does not allow this interaction, although the user should interact with the trapped door in his zone (zone8 region).
This also affects all interactable blocks and entities.

The 3rd party plugin WorldGuardFix (http://dev.bukkit.org/bukkit-plugins/betterworldguard/) fixed these problems (among others), but it sounds useless to let another plugin fix WorldGuards inheritance bugs.

Please fix these issues as soon as possible. If this behaviour is wanted, I suggest to enable multiple flag settings for a region (e.g., allow for members, deny for non-members).

Thank you
Tristan

Comment by equinox

Yeah sry, was kinda confused, too. I did not mean flags, but owners/members.

Again (for the first example http://i.imgur.com/wwuJtXj.png): The user d1rty is only a member of the city9 region and is allowed to access chests. Chest access for the zone9 region is only allowed to members (see flags), but the user d1rty still can open the chest (while the region zone9 has no owners/members).

However, your answer did not contain a solution for this specific problem.

Comment by equinox

Hello again,

we still have no solution for this. Are you still working on this?

Regards

Comment by equinox

Hello again. and again.

Is this still being watched?

Comment by wizjany

bumping issues won't get anything done faster, if anything, you're just annoying the devs and pushing your issues down the the end of their to-do list.

Comment by sk89q

With the first case, be aware that the effective flags in city8 and zone8 are:

• chest-access -g members: allow
• interact: allow

A user that is not part of the region evaluates to NONE with the first flag, but the interact flag evaluates to ALLOW. Because ALLOW overrides NONE, non-members are given access.

The interact flag is still active so you have to manually unset it (deny -g nonmembers). Higher priorities do not disable all flags that were found on previous priorities. If that were the case, a lot of things would not work anymore (i.e. global regions would be completely overridden by regular regions).

In the second case, I'm not sure if the problem is just limited to chests, but chests would not be usable by members because there are two effective flags:

• interact -g non_members: deny
• chest-access: deny

Chest access involves checking both flags, and while the first one would evaluate to ALLOW, the second flag evaluates to DENY and DENY overrides ALLOW.

Comment by wizjany

I think this is the same as WORLDGUARD-3215
As mentioned there, this is less of a bug and more of the intended behavior not matching certain expected behaviors.

Comment by equinox

I don't think that these two problems can be compared at all.

As I see the current implementation, WorldGuard priorities are completely useless when higher priorized regions inherit flags (permissions) from a lower priorized region.

However, how would you solve this specific problem?

Comment by wizjany

i'm kind of confused, why do you say the higher priority region is inheriting a flag? it's explicitly set on both regions.