Page MenuHomePhabricator

NamespaceInfo::getRestrictionLevels does not correctly handle group permissions
Closed, DuplicatePublic


(Paraphrasing what @Simetrical wrote on Gerrit, change I1e9aca6)

  • Problem analysis:**

Restriction levels are only available if there is at least one *group* that can edit the namespace but would be blocked by the restriction. This is wrong, because a user can belong to multiple groups, and a namespace can require multiple different permissions at the same time to edit.

Thus there could be two groups, neither of which can edit the namespace by itself, but someone who's in both could edit the namespace. The old code would look at each group separately and see that it couldn't edit the namespace, so it would be ignored. Then it would conclude that no restriction levels apply.

Proposed solution:

Instead, we need to find if any *combination* of groups can edit the namespace but would be blocked by the restriction level. Going through each combination is not practical (superexponential time complexity). But we can observe that if there is at least one permission required for the namespace such that every group with that permission an overcome the restriction, the restriction is not useful in that namespace.

Inversely, if for every permission required for the namespace, there is some group with that permission that cannot overcome the restriction, it is possible to have a user who can edit the namespace but not overcome the restriction. Let the user's groups be constructed as follows: for each permission, give the user a group that has that permission but cannot overcome the restriction under consideration.

Thus we have found a necessary and sufficient condition for the namespace restriction to be useless for this namespace, which can be computed efficiently.