Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-10686

Some space permissions lost after upgrade to 2.7.1

XMLWordPrintable

      The upgrade task ConsolidatePermissionsUpgradeTask may remove some space permissions during upgrade which cause users to lose some or all of their space permissions when using a case sensitive database.

      Symptoms

      • Affected users appear in the logs for the ConsolidatePermissionsUpgradeTask as having duplicate permissions removed from a space
        Example log messages
        [atlassian.confluence.upgrade.ConsolidatePermissionsUpgradeTask] doUpgrade Consolidating SpacePermissions for Space Example Space (key=Example Space).
[atlassian.confluence.upgrade.ConsolidatePermissionsUpgradeTask] removeDuplicateSpacePermissions Duplicate SpacePermission [REMOVEBLOG,0,null,Joe User] removed.
[atlassian.confluence.upgrade.ConsolidatePermissionsUpgradeTask] removeDuplicateSpacePermissions Duplicate SpacePermission [CREATEATTACHMENT,0,null,Joe User] removed.
...
      • Users no longer have their assigned permissions in the spaces
      • In the space permissions, rows for "Unknown User" appear. The permissions for this user cannot be removed

      At present this has been reported as affecting personal spaces exclusively, but it might be possible for this to affect other spaces.

      Cause

      It appears that the upgrade task may remove space permission records which are used by the HibernateSpacePermissionDao to correctly associate permissions to users. This occurs because the upgrade task is designed to consolidate permissions assigned to users which only vary by the case of the user name. Unfortunately the permission dao performs a case sensitive lookup against permissions and it is possible that the lookup will no longer match the correct records. The upgrade task is not particular with which record it deletes when consolidating the permissions.

      Resolution

      The attached class should allow the space permission lookup to find the permissions by performing a case insensitive lookup against the space permission table. We may need to look at a different approach to mitigating this problem in a future release of Confluence (e.g. a fix to the upgrade task perhaps)

      To install this patch, shut down Confluence, make the necessary directories and copy the class to confluence_installation/WEB-INF/classes/com/atlassian/confluence/security/persistence/dao/hibernate/HibernateSpacePermissionDao.class

      Permissioning should work correctly once Confluence is restarted.

        1. HibernateSpacePermissionDao.class
          5 kB

            [CONFSERVER-10686] Some space permissions lost after upgrade to 2.7.1

            Don Willis added a comment -

            Dave L and I paired on this fix.
            We rewrote the SpacePermissions/GlobalPermissions pages considerably. The general principal was to make the output of the page more thorough and to not hide any broken permissions.

            The pages used to work approximately like this:

            • Get list of users (or groups) who have the guard permission (use confluence/view space). The list only includes users who can be retrieved from the UserAccessor, so users with problems, such as those in a temporarily offline LDAP repository, or those who can no longer be looked up case insensitively, are excluded.
            • A table row with the guard permission ticked is produced for each of these users.
            • For each user, the page looks up whether they have each permission. The result of this check is a little undefined depending on whether the database is case sensitive.

            It now works like this:

            • All the permissions are arranged into a large table of permissions, with each row keyed by exact username or group name.
            • Every permission (nearly) is displayed regardless of whether the user can be found. Permissions for usernames that differ only by the capitalisation of the letters are displayed on different rows.
            • If a user or group cannot be found an error message is displayed underneath the username or group name.
            • If a user or group lookup returns a user or group with a name that has the wrong case, an error message is displayed undernate the username or group name.

            The "nearly" is because exact duplicate permissions are only displayed once.

            Fixing permissions broken by the 2.7.1 fix

            We provide a "admin/fixCaseInSpacePermissions.jsp" for administrators who have many wrongly cased permissions. This checks for space permissions that have usernames that only match users in a case-insensitive lookup, and changes the permission's username to have the correct case.

            Don Willis added a comment - Dave L and I paired on this fix. We rewrote the SpacePermissions/GlobalPermissions pages considerably. The general principal was to make the output of the page more thorough and to not hide any broken permissions. The pages used to work approximately like this: Get list of users (or groups) who have the guard permission (use confluence/view space). The list only includes users who can be retrieved from the UserAccessor, so users with problems, such as those in a temporarily offline LDAP repository, or those who can no longer be looked up case insensitively, are excluded. A table row with the guard permission ticked is produced for each of these users. For each user, the page looks up whether they have each permission. The result of this check is a little undefined depending on whether the database is case sensitive. It now works like this: All the permissions are arranged into a large table of permissions, with each row keyed by exact username or group name. Every permission (nearly) is displayed regardless of whether the user can be found. Permissions for usernames that differ only by the capitalisation of the letters are displayed on different rows. If a user or group cannot be found an error message is displayed underneath the username or group name. If a user or group lookup returns a user or group with a name that has the wrong case, an error message is displayed undernate the username or group name. The "nearly" is because exact duplicate permissions are only displayed once. Fixing permissions broken by the 2.7.1 fix We provide a "admin/fixCaseInSpacePermissions.jsp" for administrators who have many wrongly cased permissions. This checks for space permissions that have usernames that only match users in a case-insensitive lookup, and changes the permission's username to have the correct case.

              christopher.owen@atlassian.com Christopher Owen [Atlassian]
              christopher.owen@atlassian.com Christopher Owen [Atlassian]
              Affected customers:
              1 This affects my team
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: