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.
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.
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.
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.
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.