Story #7210
closedAs a user, I can configure the permissions created at object creation time
100%
Description
Problem¶
When a user creates an object, e.g. a Task, what permissions are assigned to it?
On some installation when object foo
is created users X, groups Y, and permissions Z should receive object foo
. On other installations they want users A, groups B, and permissions C to be assigned. How can we make this satisfy everyone?
Solution¶
Add a post_create_callable
JSONField to the AccessPolicy model which will be a list of dictionaries. Each dictionary will have three allowed keys, see the example entry below.
[{
"function": "add_for_users",
"parameters": ["alice", "bob"],
"permissions": ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"]
},
{
"function": "add_for_groups",
"parameters": "foo",
"permissions": "pulpcore.view_task"
},
{
"function": "object_creator",
"parameters": null,
"permissions": ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"]
}
]
Each entry will be a function called at object creation time. These methods are callables on the AccessPolicy object linked to the ViewSet, not on the model itself.
All three keys are required. The function
value is a single string which will be validated to be a callable on the AccessPolicy governing the policy. The parameters
can either be null
, a single string, or a list of strings. The permissions
case can either be a single string or list of strings, and each entry is validated against a permission in the DB.
Built in callables¶
By default three callables will always be available, but plugin-writers can add more.
-
add_for_users
will add thepermissions
for one or more users by name. This requiresparameters
to not benull
.* -
add_for_groups
will addthe permissions
for one or more groups by name. This requiresparameters
to not benull
. -
object_creator
will addthe permissions
to the creator of the object. This requires theparameters
value to be `null.
The Default¶
Plugin writers are expected to ship a default like this one:
[{
"function": "object_creator",
"parameters": null,
"permissions": ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"]
}]
How Users Configure This¶
This will be available via the AccessPolicySerializer
similar to how users read/set/adjust the statements
part today as part of story https://pulp.plan.io/issues/7160. This JsonField will be named permissions_assignment
.
Role Based Access Control
This PR adds in user-manageable Access Policies rooted at the
/pulp/api/v3/access_policies/
endpint. This deifnes both statements of the policy as well as what permissions should be created for new objects.The
/pulp/api/v3/tasks/
endpoint is now protected by an AccessPolicy which by default provides user-isolation. This effectively limits a non-admin user to only view their own tasks.Plugins writers can enable role base access control easily using the
pulpcore.plugin.models.AccessPolicyFromDB
object and declaring with thepermission_classes
attribute.Plugin writers can use the
pulpcore.plugin.models.AutoAddObjPermsMixin
which provides user-configurable ways to create permissions for new objects. This includes three methodsobject_creator
,add_for_users
, andadd_for_groups
.Plugin writers can use the
pulpcore.plugin.models.AutoDeleteObjPermsMixin
which provides auto-removal of object level permissions during object deletion.pulpcore.plugin.models.BaseModel
now usesdjango-lifecycle
allowing subcalsses to use it instead of signalsPlugin writers can easily provide queryset scoping on ViewSets that inherit from the
pulpcore.plugin.viewsets.NamedModelViewSet
by declaring thequeryset_filtering_required_permission
class attribute naming the permission required to view an object.closes #7160 closes #7210 closes #7151 closes #7157 closes #7158 closes #7300 closes #7301