Inspect Permissions returns incorrect information in Confluence 7.3
This article only applies to the Atlassian Server and Data Center platform. The contents of this article do not apply to the Atlassian Cloud platform.
Problem
In Confluence 7.3.0 we introduced two new features designed to help users, space admins, and Confluence administrators explore and troubleshoot permissions in Confluence:
- People who can view - available with a Server or Data Center license, shows users a list of people who can view the current page
- Inspect permissions - available with a Data Center license, allows space admins and Confluence admins to look up permissions information by user or group.
We've discovered that these new features don't handle some external directory configurations. Specific problems are listed below.
- Nested groups
- Non-aggregating membership
- Disabled directories
- Disabled user accounts in one, but not all, directories
These problems were resolved in Confluence 7.3.4.
Nested groups
The Inspect permissions and People who can view features are not taking into account permissions granted by a parent group, where you have nested groups in your external user directory. This means when you Inspect permissions for a user, it may report that the user does not have permission, when they actually do.
Say your external user directory has the following group structure:
The all-staff group grants the global Can Use Confluence permission, and also allows members of that group to view some spaces.
The design, development, and finance groups are nested under the all-staff group. Put another way, each of these groups is a member of the all-staff group. These groups provide specific permissions to team and project spaces.
If we were to go to the Design Team's space and inspect permissions for a user in the design group, it reports correctly that the user is a member of the design group, but does not recognise that the design group is a member of the parent group all-staff, which is the group that provides permission to use Confluence.
The end result is that Inspect permissions reports that the user can't view the space (or log in), when in fact , they can.
To check whether your site is currently impacted by this problem, run the following query:
select s.spacekey as "SPACE KEY", parent.group_name as "PARENT GROUP WITH PERMISSIONS", child_group.group_name as "CHILD GROUP"
from cwd_membership m, cwd_group parent, cwd_group child_group, spacepermissions perms left join spaces s ON perms.spaceid = s.spaceid
where m.child_group_id is not null
and m.parent_id = parent.id
and m.child_group_id = child_group.id
and parent.group_name = perms.permgroupname
group by parent.group_name, s.spacekey, child_group.group_name;This will return a list of the spaces where parent groups and child groups have permissions. It's in these spaces that the Inspect permissions and People who can view information will be inaccurate.
If no spaces are returned, then your site is not currently impacted by this problem.
Non-aggregating membership
If you have multiple user directories, Confluence automatically aggregates each user's group memberships across all those directories. However, it is possible to disable this behaviour using the REST-API, so that Confluence only ever looks at the first directory a person appears in, and only takes their group memberships from that directory. The directory order determines which directory Confluence checks first.
The people who can view and Inspect permissions features do not respect this setting, and continue to check all directories, aggregating the group memberships for each user.
Say you have three user directories with the following directory order:
In this example our user is:
- not present in directory 1 (AD)
- a member of the confluence-users and sydney groups in directory 2 (LDAP)
- a member of the confluence-users, developers and sydney groups in directory 3 (Confluence's internal directory).
Because aggregated group membership has been manually turned off in this site, Confluence only checks the first directory the user is found in when deciding what this user can do. In this example that's directory 2. As far as Confluence is concerned, this user is only a member of confluence-users and sydney.
The People who can view and Inspect permissions features don't respect the non-aggregated membership setting. If we were to inspect permissions for the user above, it would report that they are a member of the developers group, and can therefore create pages in the Development Team space, when in fact they're not able to do this because Confluence only uses the groups in directory 2 to determine what they can do.
To check whether membership aggregation is disabled in your site:
- Log in with System Administrator global permissions.
- Go to
<base-url>/rest/crowd/latest/application
If it returns that membership aggregation is not enabled (as below), your site is impacted by this problem.
<application membershipAggregationEnabled="false">If it returns true your site is not impacted by this problem.
Disabled directories
If you have multiple user directories, Confluence aggregates each user's group memberships across all those directories by default. If you disable one of your user directories, Confluence will skip that directory when aggregating group membership, and deciding what a user can do.
The people who can view and Inspect permissions features continue to check all directories, including directories that are disabled.
Say you have two user directories, and one of them is disabled:
In this example our user is a member of the confluence-users, design and sydney groups in directory 1 (the disabled directory), and the confluence-users and sydney groups in directory 2 (the enabled directory).
When deciding what the user can do, Confluence skips directory 1, because it's disabled, and uses the memberships in directory 2.
The People who can view and Inspect permissions features continue to check all directories, including the disabled directory. If we were to inspect permissions for the user above, it would report that they are a member of the design group, and can therefore create pages in the Design Team space, when in fact they're not able to do this because they are not a member of the design group in any enabled directory.
To check whether you have any disabled external user directories, go to Administration menu 
, then General Configuration > User Directories. Here's an example of what a disabled (inactive) user directory looks like in the list.
If you do have a disabled directory, your site is impacted by this problem. The extent to which you are impacted depends on how different the users and group memberships in each directory are.
User account is disabled in one of multiple directories
If you have multiple user directories, Confluence aggregates each user's group memberships across all those directories by default. If a user account is disabled in one (but not all) of those directories, Confluence will disregard any memberships the user has in that directory when deciding what the user can do.
The people who can view and Inspect permissions features checks all directories, and doesn't differentiate between directories where the user is enabled or disabled. It's only when the user is disabled in all directories, that these features display the correct information.
Say you have two user directories:
In this example our user is:
- a member the confluence-users and finance groups in directory 1, but their user account is disabled
- a member of the confluence-users and sydney groups in directory 2.
When deciding what a user can do, Confluence disregards the user's memberships in directory 1, because the user's account is disabled in that directory, and instead relies on the memberships in directory 2.
The People who can view and Inspect permissions features continue to aggregate the memberships from directory 1 and 2, and don't take into account the fact the user is disabled in directory one. If we were to inspect permissions for the user above, it would report that they are a member of the finance group, and can therefore create pages in the Finance Team space, when in fact they're not able to do this because they are not a member of the finance group in directory 2.
There is no easy way to check whether your site is impacted by this problem, but if you have multiple directories and suspect that the state of users in each directory might differ, you should assume you could be affected.
Cause
The Inspect Permissions and People who can view features does not take into consideration complex directories setups, such as nested groups, or where membership aggregation has been turned off.
It's important to note that this problem does not affect how permissions are enforced by Confluence. It just means that the Inspect permissions and People who can view feature may report incorrect information. See the examples above for a more detailed look at how this might manifest itself in your site.
Workaround
If your site is impacted by this problem, we recommend you temporarily disable the Inspect Permissions - Gatekeeper system app. This will prevent users and admins from relying on permissions information that is inaccurate.
- Go to Administration menu then Manage apps.
- Select System Apps.
- Search for the Inspect Permissions - Gatekeeper app.
- Choose Disable.
The People who can view and Inspect permissions features will no longer be accessible. You'll be able to re-enable this app once we have a fix for this problem.
Resolution
Upgrade to Confluence 7.3.4 or later.
In Confluence 7.3.4 we've improved how the People who can view and Inspect Permissions features work with complex external directory scenarios.
There's one limitation. Where you inspect permissions for a specific group, we only report the permissions granted directly to that group, and warn you that we're not showing permission granted to any parent groups. This limitation only applies when you inspect permissions for a group. When you inspect permissions for a user, we display permissions granted by all groups, including parent groups.