Admins of a team's organization show as un-removable ADMIN entry in permissions of resources

[benapetr]

ISSUE TYPE

• Bug Report

SUMMARY

See this video: https://petr.insw.cz/tmp/awx_bug.mov

You can see that there is a team existing - with 2 users, who are admins in their organization, but not AWX system admins. They are automatically also admins of the team.

Then I open inventory belonging to completely different organization and using permission system I grant their TEAM use and read permissions.

Instead the UI starts showing them as admins of inventory WITH NO option to remove them from there.

ENVIRONMENT

• AWX version: 5.0.0
• AWX install method: docker on linux
• Ansible version: 2.8.1
• Operating System: RedHat
• Web Browser: Firefox

STEPS TO REPRODUCE

Create a new organization, add some users there. Create a new team in this organization.

Grant any permissions to this new team on any inventory - they will become admins instead

EXPECTED RESULTS

I expect team permissions to be granted instead

ACTUAL RESULTS

Users became "non-team" local admins of inventory - or it appear so in UI (not sure if they really have admin powers)

ADDITIONAL INFORMATION

This strange behaviour is happening since very early AWX versions, to be honest I think it was always broken, I reported this in past, but nobody cared. Hopefully this video will make clear what is wrong.

[benapetr]

Same problem with other items - such as templates, or anything that you can define permissions for. There seems to be some flaw in whole permission mechanism.

[wenottingham]

This is a display issue only, they don't actually have those permissions.

[wenottingham]

It may be an API issue in how access_list is populated for the UI to read, given that the user's admin access in org A is showing up in the access list (under indirect_access) for the inventory in org B. CC @AlanCoding

[AlanCoding]

I have reproduced the reported issue. I will recap the minimal steps to obtain this:

• Create an organization (I name "alan" here)
• Create 1 user who is admin of the org (I name "alan_admin" here)
• Create a clean inventory in another org
• Create a team in the org
• Grant the team read_role to the inventory

Reproduction:

I agree that this is an API bug (and a high-impact one), but I do not have an actionable proposal to fix it without changing the schema / display of the access list. This comes down to the objections I had when implementing #1087. These complex indirect permissions are too information-dense to show in what we currently have for the access list display.

Talk through the fix, say you were serializing a user who had some org-level role that gave permission to the object. That could be either via a team, not via a team, or both. You could take the intersection of the descendents of the org role and the ancestors of the object roles and check if there is a team role in there. That would only establish that a team connection existed, but there could still remain a parallel path that doesn't go through the team role. If we sloppily fixed this by changing the type of display in this case, it would lead to showing a role access lower than what is real when multiple forms of access of present. This requires some form of path traversal.

If you want to get into path traversal within the RBAC hierarchy, you might be interested in my comments here:

#3600 (comment)

Regarding this issue, I can verify that "alan_admin" user in my reproduction steps does not, in fact, have admin access to the inventory:

In [16]: alan_admin in inv.read_role
Out[16]: True

In [18]: alan_admin in inv.admin_role
Out[18]: False

The fact that we show "ADMIN" is simply because that's the name of the role the user possesses (organization admin role), and the permission does not fit into any of our other explicitly serialized types. Those types are:

• direct role access
• direct team access
• indirect team access

It might be confusing that this doesn't fit "indirect team access", but that only means "indirect" in the sense of downstream from the team role. This case is indirect connections upstream of the team role.

As a band-aid fix, I'm sure I could work something out to specifically serialize another category of "indirect team access upstream", but this leaves open the door for still much more complexity in the case of indirect-indirect (indirect membership to the team, indirect access from the team role to the object roles) team access. But this would only allow us to add an entry to show the team permission, and would not take away the un-removable "ADMIN" box shown in the UI. For that, I say we need a more comprehensive fix that involves the UI.

[wenottingham]

addressed in #4529

[dsesami]

seems that this is related to the fix for indirect access permissions, so I tried out the scenario here. I tried giving the org admin user both read and execute permissions; it displays correctly depending on the level i assign it, and has a tooltip explaining why -- also, removing admin powers moves it to team permissions, if they exist. Marking as closed as this seems correct.