The current plan for our RBAC implementation in pulp involves assigning roles on objects to users, so that the creator of e.g. a repository will eventually be the owner of it.
But this concept is not extended to content. And that way, strange behavior emerges. If you say, only content in a repository you can access is visible to you, then you will be unable to see (and use) the very content you just uploaded without adding it to a repository in the very same rest call. If we do not impose any restriction on viewing existing content at all, that is definitely not secure. Should we add permissions and access policies to the content in much the same way as for other objects, you may try to upload a content that already exists, yet is invisible to you (I believe you should be added the corresponding roles in that case). When i sync, content into a repository, should it inherit all the roles from it (this potentially busts the UserRoles table)? Should we add a (hidden) repository per user to track their “owned” content (busts another table, but the information must go somewhere, no?)?
Good thing: For content being immutable it’s no problem to have multiple mutually untrusted entities registered as “owner”.
What i’d expect from the final design:
- If i cannot see a specific content, i can upload it, and handle it in exactly the same way (including a “201 created” response by the server) as if it was new to Pulp.
- Optional: As long as i can see content, it is protected from orphan cleanup.
- Optional: I can trash content (resign the viewing permission).
- I can grant viewing permission of content i see to other users.
- I can filter content, i can see by direct/indirect permission.
- This obviously does not apply if i permissions for synced content are explicitly granted.