Require superuser permission to revoke global roles

[AlanCoding]

Policy edit to be what AWX prior is_system_auditor policy was.

I gave more detail in a followup comment, but here are the key changes:

• Require superuser permission to revoke a system role assignment
• Allow removing an assignment if it applies to yourself
• Require that adding/revoking global role assignments only involve non-shared model permissions

AAP-26308

[AlanCoding]

This is flawed. Because it would prevent a system auditor from demoting themselves from being a system auditor. We did support that in the old AWX logic, at least for a user editing event.

[AlanCoding]

Walking back through from the beginning:

Original story of concern:

• A user who is a system auditor tries to revoke another user's system auditor role assignment
• Previously this would have been allowed, but this patch changes it to a 403, which is consistent with prior AWX behavior

However, the obvious fix for this would open up another user story (test_remove_global_assignment_yourself) that is likely to regress:

• As a user who has the system auditor role, try to revoke your own assignment to that role
• This should be allowed, which is consistent with prior AWX behavior.

The reason this needs to be stated is that our prior criteria ("you can remove a system role assignment if you have all its permissions") covered that case implicitly. So this needs to add an explicit criteria that you can remove assignments for a given user, regardless of the associated object, or regardless of it being a system role.

There is another object-role variant of this scenario (test_remove_object_assignment_yourself).

• A user has "view" permission to an object
• That user tries to revoke their role assignment (wants themselves to no longer be able to view the object)
• Prior behavior looks like this would have given a 403, which is a bug. You should always be able to remove your own role assignments.

I saw another fairly nuanced problem with system roles (test_auditor_for_external_models). This is overlapping with recent merge https://github.com/ansible/django-ansible-base/pull/501, which added an exception for "view" permission to objects, but this adds an exception-to-the-exception for system roles.

• A system-wide auditor role that comes from a permission-provider service. We say it is externally managed here if it includes any permissions for shared resources.
• Someone tries to assign or revoke that role.
• Prior behavior was that this would be allowed, but that is inconsistent with other rules for externally-managed roles. So this changes it to a 403.

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[AlanCoding]

What I'm not sure, how user can delete own global permission

Code-wise, on assignment DELETE requests check_can_remove_assignment is called for the permission check, and (given a user assignment) if they can make changes to the user, this unconditionally returns without error. You can make changes to a user if that user is yourself.