Rights, implied rights and resolution of rights

[surli]

Hi everyone,

this topic aims at being a brainstorming to start to clarify a bit some behaviour of our Right mechanism, and maybe start some changes for it. I’m starting it because I found recently a behaviour that I consider as a bug since that’s not what I was expected, I already discussed it a bit with @tmortagne who agreed that it feels like a bug, now changing that behaviour might expose to some deep changes in the way Rights are resolved inside XWiki, so I prefer to start discussing it here.

Let’s take the following scenario:
I have an instance of XWiki, on which I have a group GroupX and a user UserA which belongs to GroupX. On this wiki, like on any instance of XWiki, the Admin Right implies some other rights: View, Edit, Script, Delete, etc.

On this instance, I’m setting the rights like this:

• GroupX doesn’t have any specific right set, except Admin Right which is allowed to it, on the whole wiki
• UserA on its side is explicitely forbidden from doing the Delete Right, but has not other right set

So the question is: in your opinion, knowing that UserA belongs to GroupX, and Admin Right implies Delete Right, do you think UserA should be allowed to delete pages?

[tmortagne]

My point of view is that it does not make any sense for a user to have ADMIN right and not have DELETE right wherever the rights or even worst having EDIT right and not VIEW right which is possible too with the same logic. For me, it defeats the whole purpose of implied rights.

[lucaa]

Hello surli,

I would guess userA will continue to be able to delete pages, because you cannot deny much to an admin (they’ll just give themselves that right back since admin means that they can change rights, and they will change it back for themselves…). Now, of course, the fact that they can give it back to themselves does not mean it should not be denied in the first place, denying may be useful for protecting against mistakes on the UI, for example.

But, of course, your question is not whether they would have the right, but whether they should have the right. A couple of thoughts over this:

• I think both behaviours are OK for me, the fact that they have it and that they don’t (but can take it back at any moment because they’re admins)
• this is a rather complex rights setup situation, my opinion is that the rights UI (not necessarily the API) should streamline towards creation of simpler situations
  • hint: using “deny” makes any situation complex.

@tmortagne

For me, it defeats the whole purpose of implied rights.

I think I understand better the question here: there is a clarification needed for the case of the tie between an implied right and an explicit deny: if the original right A that implies another right B is not denied, but right B is denied explicitly, should the deny be honored or not?
@surli if this is your original question, choosing admin & delete makes your example a particular case, because admin is a special right (non deniable).

So, if I’d need to answer this question:
tie between an implied right and an explicit deny: if the original right A that implies another right B is not denied, but right B is denied explicitly, should the deny be honored or not?

I would say yes, the deny should be honored.

Not because it’s a much better solution (as Thomas said, it does create an incomprehensible situation from the pov of implied rights) but because the alternative - of ignoring that deny - is worse . Also, as I said above, deny is a special thing anyway that one should use rarely to create “exceptions” (“all the normal behaviour except for this right for these people”) and honoring that deny allows just that, to create exceptions of normal situations of implied rights.
Of course, this may take a different form for the case of rights that are undeniable (as presented here https://extensions.xwiki.org/xwiki/bin/view/Extension/Security%20Module#HDefaultrightsbeingpredefined ) for which we do ignore the deny - at least for the right itself, so maybe we can ignore it for the implied rights as well .

[surli]

@lucaa

I think I understand better the question here: there is a clarification needed for the case of the tie between an implied right and an explicit deny: if the original right A that implies another right B is not denied, but right B is denied explicitly, should the deny be honored or not?
@surli if this is your original question, choosing admin & delete makes your example a particular case, because admin is a special right (non deniable).

So yes I guess the question could be formulate like that. Now I’m not sure why you mean it’s a special case with admin being non deniable, if I’m reading back the doc from Security Module (XWiki.org) the “non deniable” in “Inheritance policy” column only means that you cannot make it deniable in a sub-level (space or doc), but you still can deny it at wiki level, and my example is given at a single level, I’m not talking about multi-level resolution here.

@lucaa

I would say yes, the deny should be honored.

Not because it’s a much better solution (as Thomas said, it does create an incomprehensible situation from the pov of implied rights) but because the alternative - of ignoring that deny - is worse

Ok so for you, in my example, UserA should be not be allowed to use delete right in my scenario.

[lucaa]

@surli

Now I’m not sure why you mean it’s a special case with admin being non deniable, […] "non deniable” in “Inheritance policy” column only means that you cannot make it deniable in a sub-level (space or doc), but you still can deny it at wiki level, and my example is given at a single level

I did think of the topic on multiple levels, indeed, not for the same level. But now I am looking at the question more technically and I found this sentence in the documentation that may add more information to this topic (in the context of not deniable rights):

Implied right receive the tie resolution policy, the inheritance override policy, and their kind of matching (user or group) from the right and the rule of the right that have implied them. For example, an edit right implied by an admin right will not be overridden by a denial of the edit right at a lower level.

So the fact of the admin being “not deniable” changes the situation because it propagates to its implied rights.
So the question, in the specific context of a not deniable right, is about whether the not-deniability should propagate to its implied rights at the same level too. It is a special case because the whole philosophy of a right being not deniable seems to be to be related to the “whole vs. part” logic: the right in question, once decided for the “whole” (a wiki), cannot be modified for a “part” (a page). It would make sense, to me, to apply the same logic for the implied rights: once decided for a “whole” (the admin right), cannot be modified for a “part” (the implied delete right), even at the same level.

I work under the assumption that the concept of not-deniability was added for a reason, that reason probably being that technically it’s not possible to be able to admin a wiki and yet to not be able to admin some of its pages.

So this makes @tmortagne 's comparison of admin → delete and edit → view rather forced, it’s not exactly the same thing, admin is not-deniable while view is and apparently there is some special behaviour for that case. But I agree that there is indeed a “whole” in the logic which is left by the fact that you can be able to edit a page that you cannot view, just because view and edit are deniable, and this is strange.

@surli

Ok so for you, in my example, UserA should be not be allowed to use delete right in my scenario.

As I said, for your example I think we need to clarify exactly if the “not deniable” part should also apply at the same level for implied rights or not.
My answer is for the general case of implied rights (that are deniable).

For your example, with admin and delete and in the light of the sentence above from the documentation, as I mentioned above I would say it makes sense to extend the not deniable policy to the implied rights at the same level as well.
As I said in my first answer, both are fine for me, as long as they are documented.

[jeffix]

If my “end-admin” POV can be of use, I’d consider whether implied means default expected behavior or functionally necessary behavior. The scenarios you mentioned hint to the “necessity” interpretation: administer requires being able to delete/move/rename, edit requires being able to view.

So I would go with sub-right denial having no practical effect.

[dgervalle]

Hi surli,

Let me first clarify what I had understood from your question and particular use case, so we avoid any misunderstanding in my reply.

You have a UserA which is a member of GroupX.
You have at main WIKI level defined two rules:

• GroupX is allowed ADMIN right
• UserA is denied DELETE right

What really matters here in regard to the DELETE right, is the fact that at the same level, it is allowed to UserA by means of a group, but more importantly, it is disallowed to UserA explicitly. This will cause the application of the following policy:

• at the same level, a right assigned by means of a user gets priority over a right assigned by means of a group

Neither the inheritance policy, nor the tie resolution policy is involved here, since there is no inheritance, nor any tie. The right set on a user simply wins over the right set or implied by a group.

Therefore, and I have not checked if this is what really happens, but I am very confident it is so, I expect the UserA to be denied the deletion of documents.

This feature is made on purpose, since it allows managing rights by means of groups while keeping possible exceptions for a user. It only happens on the same level, and therefore is quite clear to understand, since it appears on the same screen, by opposition to the right inherited, which is much more difficult to understand.

Of course, depending on the right to consider, and the ADMIN right is definitely the poor example, it just prevent the user from deleting by mistake, but does not prevent him from changing its own rights if he really wants to achieve his goal.

I would not change anything, since I am certain this kind of use cases have a meaning in certain situations, and on the other hand, it cannot really hurt, since both rules are visible in the same screen. Also, never forget that the security module is extensible, and could be used for other rights than the base ones, and that you can also replace the right settler if you really need to. So it deserve to be made more general than any particular use case IMO.

Finally, your use case does not follow the common best practice which is to disallow rights by allowing them to others, and is therefore an advanced usage of the right policies. That’s the price to pay when you go advanced, it to understand the very details of the right policies.

Let me know if I have misunderstood your question.

[surli]

Hi Denis,

thanks for coming back to give your input on this

@dgervalle

I have not checked if this is what really happens, but I am very confident it is so, I expect the UserA to be denied the deletion of documents.

This is indeed what happens right now.

@dgervalle

Also, never forget that the security module is extensible, and could be used for other rights than the base ones

So for the context I found this while debugging a situation with an extension right, but apparently my bug was finally not related to this behaviour.

@dgervalle

Finally, your use case does not follow the common best practice which is to disallow rights by allowing them to others, and is therefore an advanced usage of the right policies.

I understand that this is the best practice policy, but even if it’s not followed we should ensure that the security module behave correctly when it’s not followed. So I understand I should be careful when using forbidden rights but I do think it’s important to be sure we get the right behaviour when we use it.

@dgervalle

Let me know if I have misunderstood your question.

Yep you got it.

So ok, I understand a bit more the way it works, and I’m a less inclined to consider the behaviour is wrong for admin / programming rights. Moreover it’s a dangerous move to change something in the security module regarding rights resolution in term of backward compatibility.
So if everyone agrees, I will just close this brainstorming.