XWiki Platform
  1. XWiki Platform
  2. XWIKI-6987

Rights management bug in user with edit rights

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Won't Fix
    • Affects Version/s: 3.1
    • Fix Version/s: None
    • Component/s: Old Core
    • Labels:
      None
    • keywords:
      rights, rights management
    • Difficulty:
      Unknown
    • Similar issues:
      XWIKI-2410Ability to filter users/groups by granted rights in the new Rights Management UI
      XWIKI-1915The new user, groups and rights management has some bugs in Firefox 3.0 beta1
      XWIKI-1963Various bugs in the new Rights Management UI
      XWIKI-8Revamping of the Rights Management
      XWIKI-2016User rights management - ClassCastException with Oracle
      XWIKI-2403No error/warning displayed in the rights management UI when the user has forbid himself from editing
      XWIKI-2636Make inherited rights visible in the Rights Management UI
      XWIKI-2068Rights Manager does not clean deleted user/group in all wikis
      XWIKI-171Complete User and Group Rights Management Documentation
      XWIKI-7521Setting explicit rights to particular user denies all existing group rights

      Description

      Two Default groups: XWikiAllGroup and XWikiAdminGroup

      Admin gives rigths to XWikiAllGroup to view pages - no problem.
      Admin gives rigths to XWikiAllGroup to EDIT pages.

      User With Edit rights has possibiity to manage access rights.
      I even tried to prohibit to XWikiAllGroup users Administration rights, nothing changed.

      If "smart user" (e.g. "Test" in XWikiAllGroup) with edit rights will:

      • prohibit access to pages to whole XWikiAllGroup OR
      • grant VIEW rights ONLY to  XWikiAdminGroup

      Then page becomes inaccessible to non-admin users. Test User can easily grant any right to admin group. It gives an error, but actually sets right.

      So, Test User can even grant himself delete rights on page, then delete page successfully even if delete right is BLOCKED for XWikiAllGroup.

      Looks Dangerous.

        Activity

        Hide
        Andreas Jonsson added a comment -

        The right service will ignore delete rights set on a document. Delete rights can only be assigned at wiki or space level. A fix would be to deny edit rights on the WebPreferences document by default in all spaces.

        This issue overlaps with XWIKI-2184.

        Show
        Andreas Jonsson added a comment - The right service will ignore delete rights set on a document. Delete rights can only be assigned at wiki or space level. A fix would be to deny edit rights on the WebPreferences document by default in all spaces. This issue overlaps with XWIKI-2184 .
        Hide
        Andreas Jonsson added a comment -

        Also, setting rights for admin users at document level will not have any effect, as admin rights always implies edit and view rights.

        Show
        Andreas Jonsson added a comment - Also, setting rights for admin users at document level will not have any effect, as admin rights always implies edit and view rights.
        Hide
        Sergiu Dumitriu added a comment -

        The right service will ignore delete rights set on a document

        Turns out that's not true, delete rights set on a document are taken into account.

        Show
        Sergiu Dumitriu added a comment - The right service will ignore delete rights set on a document Turns out that's not true, delete rights set on a document are taken into account.
        Hide
        Andreas Jonsson added a comment -

        ... delete rights set on a document are taken into account.

        Hmm, in that case my analysis of the right service implementation is not as thorough as I thought. (In my reimplementation, I am ignoring delete rights at the document level.) This raises an interesting question: will admin and programming rights also be considered at page level? These are not possible to set via the rights UI, but they are possible to set via the regular object api.

        Show
        Andreas Jonsson added a comment - ... delete rights set on a document are taken into account. Hmm, in that case my analysis of the right service implementation is not as thorough as I thought. (In my reimplementation, I am ignoring delete rights at the document level.) This raises an interesting question: will admin and programming rights also be considered at page level? These are not possible to set via the rights UI, but they are possible to set via the regular object api.
        Hide
        Andreas Jonsson added a comment -

        I had another look at XWikiRightServiceImpl and programming rights are not considered at document level.

        But it seems that the method hasAccessLevel will consider admin rights at the document level, although the method hasAdminRights will not. In other words, it seems that a non-admin with edit rights can arrange so that hasAdminRights(ctx) == false and hasAccessLevel("admin", ctx.getUser(), ctx.getDoc().getFullname(), ctx) == true. I'm not sure if this is exploitable.

        Show
        Andreas Jonsson added a comment - I had another look at XWikiRightServiceImpl and programming rights are not considered at document level. But it seems that the method hasAccessLevel will consider admin rights at the document level, although the method hasAdminRights will not. In other words, it seems that a non-admin with edit rights can arrange so that hasAdminRights(ctx) == false and hasAccessLevel("admin", ctx.getUser(), ctx.getDoc().getFullname(), ctx) == true. I'm not sure if this is exploitable.
        Hide
        Andreas Jonsson added a comment -

        The situation looks dangerous, indeed:

        xwikivars.vm:
        #set ($hasAdmin = $xwiki.hasAccessLevel('admin'))
        
        XWiki.java:
        
            public boolean hasAccessLevel(String level)
            {
                return hasAccessLevel(level, getXWikiContext().getUser(), getXWikiContext().getDoc().getFullName());
            }
        
        Show
        Andreas Jonsson added a comment - The situation looks dangerous, indeed: xwikivars.vm: #set ($hasAdmin = $xwiki.hasAccessLevel('admin')) XWiki.java: public boolean hasAccessLevel( String level) { return hasAccessLevel(level, getXWikiContext().getUser(), getXWikiContext().getDoc().getFullName()); }
        Hide
        Andreas Jonsson added a comment -

        Now I have tested and admin rights does not seem to be considered at document level, although this is not obvious from the code.

        Delete rights are, however.

        Show
        Andreas Jonsson added a comment - Now I have tested and admin rights does not seem to be considered at document level, although this is not obvious from the code. Delete rights are, however.
        Hide
        Sergiu Dumitriu added a comment -

        Admin and programming rights definitely shouldn't be considered at document level. I'm not sure about delete rights. I'd be in favor of also ignoring them at the page level, but this would be a backwards-incompatible change. Will start a vote about this...

        Show
        Sergiu Dumitriu added a comment - Admin and programming rights definitely shouldn't be considered at document level. I'm not sure about delete rights. I'd be in favor of also ignoring them at the page level, but this would be a backwards-incompatible change. Will start a vote about this...
        Hide
        Andreas Jonsson added a comment -

        I will commit a patch that disallows edit rights on WebPreferences and XWiki.XWikiPreferences for non-admin users. Also, I noticed that hasAccessLevel("admin", ... ) will return true by default. I'm changing to deny by default.

        This will break compatiblity, but to me this seems like the behavior that one would expect, so I'll go ahead and commit without initating a vote.

        Show
        Andreas Jonsson added a comment - I will commit a patch that disallows edit rights on WebPreferences and XWiki.XWikiPreferences for non-admin users. Also, I noticed that hasAccessLevel("admin", ... ) will return true by default. I'm changing to deny by default. This will break compatiblity, but to me this seems like the behavior that one would expect, so I'll go ahead and commit without initating a vote.
        Hide
        Vincent Massol added a comment -

        I haven't thought too much about this but on first look I don't like too much that we have some special hardcoded rule in the core of XWiki about this (since WebPreferences and XWikiPreferences are "normal" documents). Why not simply have a page level right on WebPreferences and XWikiPreferences? Wouldn't that be enough?

        At least can you tell me that it's possible to override the default hardcoded rule by setting a page level access right on those documents?

        Show
        Vincent Massol added a comment - I haven't thought too much about this but on first look I don't like too much that we have some special hardcoded rule in the core of XWiki about this (since WebPreferences and XWikiPreferences are "normal" documents). Why not simply have a page level right on WebPreferences and XWikiPreferences? Wouldn't that be enough? At least can you tell me that it's possible to override the default hardcoded rule by setting a page level access right on those documents?
        Hide
        Andreas Jonsson added a comment -

        It is possible to explicitly deny edit rights for XWikiAllGroup and XWikiGuest on all WebPreferences documents.

        I agree that this is an ugly solution, but my rationale for this is that it is a simple fix that will work for all current installations. The alternative is to run an upgrade script that denies these rights and to have a hook that denies them whenever a new space is created. Also, some installations might not use the group XWikiAllGroup. So the alternative is more complex and more fragile.

        It would not be possible to override the hardcoded rule. But from the point of view of enforcing access levels, it is essentially the same thing to assign admin rights and edit rights to a WebPreferences document, so you might just as well assing admin rights instead

        Show
        Andreas Jonsson added a comment - It is possible to explicitly deny edit rights for XWikiAllGroup and XWikiGuest on all WebPreferences documents. I agree that this is an ugly solution, but my rationale for this is that it is a simple fix that will work for all current installations. The alternative is to run an upgrade script that denies these rights and to have a hook that denies them whenever a new space is created. Also, some installations might not use the group XWikiAllGroup. So the alternative is more complex and more fragile. It would not be possible to override the hardcoded rule. But from the point of view of enforcing access levels, it is essentially the same thing to assign admin rights and edit rights to a WebPreferences document, so you might just as well assing admin rights instead
        Hide
        Andreas Jonsson added a comment -

        I should also add that I consider this fix temporary until we add a special right to assign rights or similarly. See XWIKI-2184.

        Show
        Andreas Jonsson added a comment - I should also add that I consider this fix temporary until we add a special right to assign rights or similarly. See XWIKI-2184 .
        Hide
        Andreas Jonsson added a comment -

        I added some unit tests for checking if admin, delete and programming rights are considered at document level. Admin rights are in fact considered. For some reason the actual exploit I attempted failed, so I'm not sure wether this is a problem or not.

        I have prepared a patch for not checking admin and delete rights at document level, but there were only one respons to Sergiu's vote about this.

        I would like to proceed with this anyway, since I cannot see any other fix without implementing XWIKI-2184.

        Show
        Andreas Jonsson added a comment - I added some unit tests for checking if admin, delete and programming rights are considered at document level. Admin rights are in fact considered. For some reason the actual exploit I attempted failed, so I'm not sure wether this is a problem or not. I have prepared a patch for not checking admin and delete rights at document level, but there were only one respons to Sergiu's vote about this. I would like to proceed with this anyway, since I cannot see any other fix without implementing XWIKI-2184 .
        Hide
        Sergiu Dumitriu added a comment -

        Also, I noticed that hasAccessLevel("admin", ... ) will return true by default. I'm changing to deny by default.

        Don't do this, since otherwise it won't be possible to install the default XAR on an empty wiki with no users. XWikiGuest must be able to access the wiki administration when no rights are set.

        Show
        Sergiu Dumitriu added a comment - Also, I noticed that hasAccessLevel("admin", ... ) will return true by default. I'm changing to deny by default. Don't do this, since otherwise it won't be possible to install the default XAR on an empty wiki with no users. XWikiGuest must be able to access the wiki administration when no rights are set.
        Hide
        Andreas Jonsson added a comment -

        I forgot about the initial import. I restored allowing admin rights by default.

        It is, however, also possible to use the superadmin user to make the initial import.

        Show
        Andreas Jonsson added a comment - I forgot about the initial import. I restored allowing admin rights by default. It is, however, also possible to use the superadmin user to make the initial import.
        Hide
        Andreas Jonsson added a comment -

        Following the discussion in this thread: http://xwiki.475771.n2.nabble.com/State-of-release-4-1-td7547747.html I'm closing this, even though it has only partially been fixed.

        Show
        Andreas Jonsson added a comment - Following the discussion in this thread: http://xwiki.475771.n2.nabble.com/State-of-release-4-1-td7547747.html I'm closing this, even though it has only partially been fixed.
        Hide
        Eduard Moraru added a comment -

        Couldn't this have been done the other way around, by just using rights?

        Instead of handling XWikiPreferences and WebPreferences specially in the platform (rights module), we could have just added a "deny" on "edit" rights for "XWiki.XWikiAllGroup" for XWikiPreferences and WebPreferences (when WebPreferences is created by an admin at first access).

        Show
        Eduard Moraru added a comment - Couldn't this have been done the other way around, by just using rights? Instead of handling XWikiPreferences and WebPreferences specially in the platform (rights module), we could have just added a "deny" on "edit" rights for "XWiki.XWikiAllGroup" for XWikiPreferences and WebPreferences (when WebPreferences is created by an admin at first access).
        Hide
        Andreas Jonsson added a comment -

        Yes that would have been possible, but then there is the problem of patching existing wiki installations.

        The root of the problem is that rights are ordinary objects that are accessed via the same api as everyting else. My plan is to provide a separate API for accessing rights, deprecate access via the object API and eventually provide a separate storage for rights and separate fields in the documents.

        Show
        Andreas Jonsson added a comment - Yes that would have been possible, but then there is the problem of patching existing wiki installations. The root of the problem is that rights are ordinary objects that are accessed via the same api as everyting else. My plan is to provide a separate API for accessing rights, deprecate access via the object API and eventually provide a separate storage for rights and separate fields in the documents.
        Hide
        Sergiu Dumitriu added a comment -

        Preferences documents are special, so they should have special treatment in the rights module. Personally I prefer the current approach, since automatically adding rights when creating a document is fragile. "XWikiAllGroup" is just a default, other wikis could use other group names.

        Show
        Sergiu Dumitriu added a comment - Preferences documents are special, so they should have special treatment in the rights module. Personally I prefer the current approach, since automatically adding rights when creating a document is fragile. "XWikiAllGroup" is just a default, other wikis could use other group names.

          People

          • Assignee:
            Andreas Jonsson
            Reporter:
            Dmitry Bakbardin
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Date of First Response: