At the moment pulp uses the default permission class from django rest framework as the base permission class for all of it’s viewsets. By default this is set to
pulpcore.plugin.access_policy.AccessPolicyFromDB, however this can be set to any permission class that implements the DRF permission class interface. As a user, if I chose to switch the default access policy to something else, I would expect this to also disable the rest of Pulp’s RBAC system however that’s not the case.
Pulp still performs the following actions that are linked to
- Populates the Access Policy database table
- Creates default roles
creation_hooksand the legacy
permissions_assignmentfunctions for every access policy that’s still configured in the DB
1 and 2 aren’t particularly problematic, however 3 can potentially lead to issues. User’s who don’t want to use the default AccessPolicyFromDB may not want permissions to be automatically assigned to objects when they’re created. At best this is an annoyance and the user will end up with a lot of unused groups. At worst this can lead to security issues if the groups used by the permission assignment functions collide with user specified groups or if the user choses create their own permission class or to use one of the other DRF base classes such as DjangoObjectPermissions or DjangoModelPermissions.
It might be a good idea to tie the auto assignment to default permission class in some way so that users who chose to customize their own permission classes can define how
creation_hooks are handled, or ignore them entirely if they want to use a permission class such as IsAdminUser that completely ignores groups.