Project

Profile

Help

Story #9614

closed

As a developer, I can mark a Model as RBAC enabled and have exceptions raised for any quersets that don't use `with_perm`

Added by bmbouter almost 3 years ago. Updated almost 3 years ago.

Status:
CLOSED - DUPLICATE
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

Ticket moved to GitHub: "pulp/pulpcore/2067":https://github.com/pulp/pulpcore/issues/2067


This is build on the introduction of with_perm.

Motivation

Everytime a queryset is constructed that deals with an RBAC enabled object, we need to ensure that only those objects that user has permissions to operate on are available in the queryset results. For example, if I have the core.delete_task permission on some objects, but not others, I can't just run Task.objects.all().delete().

We deal with querysets in so many places, it would be great to have a safer way to be told if I've filtered each queryset at least in some way by permissions.

Proposal

Add an attribute on all models called RBAC_PROTECTED = False and have models opt-in to using this safety feature by setting it to True on their model definition.

Then modify the querset evaluation to raise an exception if that queryset never had a with_perm call occur. This would be an opt-in, model-by-model safety feature.

There are some situations when you are supposed to not need a with_perm call. For example if the viewset queries for all objects, and then passes the list of pks to the task in the backend to handle, the backend queryset construction already handled permissions but there is no call to with_perm there.

Let's add a queryset method called qs.with_no_perms(). With this I could call Task.objects.with_no_perms().all() and I would not receive the exception even without a call to with_perm.

Special considerations

There could be situations where a new querset is made as a new object, e.g. boolean or set operations. Let's get examples of these kinds of situations right:

  • qs.all() | qs.with_perm("core.task_show") -> unsafe
  • qs.none() | qs.with_perm("core.task_show") -> safe
  • qs.none() & qs.with_perm("core.task_show") ??
  • qs.all() & qs.with_perm("core.task_show") -> safe

Related issues

Blocked by Pulp - Story #9613: As a developer, I can make permission object filtering chainableCLOSED - DUPLICATE

Actions
Actions #1

Updated by bmbouter almost 3 years ago

  • Related to Story #9613: As a developer, I can make permission object filtering chainable added
Actions #2

Updated by bmbouter almost 3 years ago

  • Related to deleted (Story #9613: As a developer, I can make permission object filtering chainable)
Actions #3

Updated by bmbouter almost 3 years ago

  • Blocked by Story #9613: As a developer, I can make permission object filtering chainable added
Actions #4

Updated by mdellweg almost 3 years ago

I would rename no_perms_warning to with_no_perm and once that is used on a queryset using with_perm should raise an exception, too.

Actions #5

Updated by bmbouter almost 3 years ago

  • Description updated (diff)

Good idea, I rewrote the story some to use with_no_perms().

Actions #6

Updated by fao89 almost 3 years ago

  • Description updated (diff)
  • Status changed from NEW to CLOSED - DUPLICATE

Also available in: Atom PDF