Adding Automatic Permissions for New Objects

When creating new objects in either viewsets or tasks it’s important to have the right permissions. It is important that the permissions new objects receive work with the AccessPolicy so that newly created objects can be authorized by the AccessPolicy as expected. The AccessPolicy statements are user-configurable and so the permissions to be created for new objects are too. Similar to the requirements for the AccessPolicy statements, plugin writers can define and ship a default behavior for permissions on new objects, and then users can modify them as needed after migrations are run.

Defining New Object Permission Behaviors

The AccessPolicy.permissions_assignment attribute defines a set of callables that are intended to be run when new objects are created. These do not run automatically; your models should use the pulpcore.plugin.models.AutoAddObjPermsMixin on the model as described in the Enabling New Object Permission Creation section.

The AccessPolicy.permissions_assignment attribute is optional because not all AccessPolicy objects create objects. If no objects are created by an endpoint, there does not need to be a permissions_assignment attribute.

The most common auto-assignment of permissions is to the creator of an object themselves. Here is an example assigning the ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"] permissions to the creator of an object:

{
    "function": "add_for_object_creator",
    "parameters": null,
    "permissions": ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"]
    }

Another common auto-assignment of permissions is to assign to one or more users explicitly. Here is an example assigning the ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"] permissions to the users ["alice", "bob"].

{
    "function": "add_for_users",
    "parameters": ["alice", "bob"],
    "permissions": ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"]
}

A third common auto-assignment of permissions is to assign to one or more groups explicitly. Here is an example assigning the "pulpcore.view_task" permission to the group "foo".

{
    "function": "add_for_groups",
    "parameters": "foo",
    "permissions": "pulpcore.view_task"
}

Note

Both the add_for_users and add_for_groups accept either a single item or list of items for both the parameters and permissions attributes.

Enabling New Object Permission Creation

To enable automatic permission creation for an object managed by an AccessPolicy, have your model use the pulpcore.plugin.models.AutoAddObjPermsMixin. See the example below as an example:

class MyModel(BaseModel, AutoAddObjPermsMixin):
   ...

See the docstring below for more information on this mixin.

class pulpcore.app.models.access_policy.AutoAddObjPermsMixin

A mixin that automatically adds permissions based on the permissions_assignment data.

To use this mixin, your model must support django-lifecycle.

To use this mixin, you must define a class attribute named ACCESS_POLICY_VIEWSET_NAME containing the name of the ViewSet associated with this object.

This mixin adds an after_create hook which properly interprets the permissions_assignment data and calls methods also provided by this mixin to add permissions.

Three mixing are provided by default:

• add_for_object_creator will add the permissions to the creator of the object.

• add_for_users will add the permissions for one or more users by name.

• add_for_groups will add the permissions for one or more groups by name.

Shipping a Default New Object Policy

In general, the default recommended is to use the add_for_object_creator to assign the view, change, and delete permissions for the object created. Here is an example of a default policy like this:

FILE_REMOTE_PERMISSIONS_ASSIGNMENT = [
    {
        "function": "add_for_object_creator",
        "parameters": None,
        "permissions": [
            "file.change_fileremote", "file.change_fileremote", "file.delete_fileremote"
        ]
    }
]

AccessPolicy.objects.create(
    viewset_name="FileRemoteViewSet",
    statements=FILE_REMOTE_STATEMENTS,
    permissions_assignment=FILE_REMOTE_PERMISSIONS_ASSIGNMENT
)

This effectively creates a “user isolation” policy which aligns with the examples from Shipping a Default Access Policy.

Defining Custom New Object Permission Callables

Plugin writers can use more than the built-in callables such as add_for_object_creator or add_for_users by defining additional methods on the model itself. The callables defined in the function are method names on the Model with the following signature:

class MyModel(BaseModel, AutoAddObjPermsMixin):

    def my_custom_callable(self, permissions, parameters):
        # NOTE: permissions and parameters can be either a single entity or a list of entities
        from guardian.shortcuts import assign_perm
        user_or_group = parameters
        for permission in permissions:
            assign_perm(permissions, user_or_group, self)  # self is the object being assigned

This would be callable with a configuration like this one:

{
    "function": "my_custom_callable",
    "parameters": "asdf",
    "permissions": "pulpcore.view_task"
}

Auto Removing Permissions On Object Deletion

A mixin is provided for use on your models to automatically delete all object-level permissions when an object is deleted. This is provided by the pulpcore.plugin.models.AutoDeleteObjPermsMixin mixin.

class MyModel(BaseModel, AutoDeleteObjPermsMixin):
   ...

See the docstring below for more information on this mixin.

class pulpcore.app.models.access_policy.AutoDeleteObjPermsMixin

A mixin that automatically deletes user and group permissions for an object prior to deletion.

To use this mixin, your model must support django-lifecycle.