---
# System prepended metadata

title: Registry pull-thru cache permissions brainstorm

---

# Registry pull-thru cache permissions brainstorming

### Registry 'cache' was created. It is private by default and newly created repos are private by default.

User Alice wants to pull-thru 'httpd' repo, but this repo does not exist yet in the 'cache' registry. User Alice will need 'create' model repo permission in the 'cache' registry

User Bob wants to pull-thru 'httpd' repo, but this repo already exists in 'cache' registry, because just before Alice has pulled. The repo remotely has updates. User Bob will need 'write' object(or model) repo permission. 'Write' because new blob might be available and new repo-version will be created.

User Frank wants to pull-thru 'httpd' repo, he has only 'read' object (or model) repo permission. He will be able to pull-thru only locally available cache, but not the new blobs if those are available at the pull moment

Anonymous user has by default no permissions granted. He wants to pull-thru 'httpd' repo, he gets 401 because repo is private and he has no permissions.

**Note** Does it make sense for simplicity and consistency during pull operation to not distinguish between Bob and Frank and have just 'write' repo permissions.

**Note** anonymous user could be granted additional permissions, e.g. 'write' object/model repo permissions, that will allow him to pull in new blobs but not create 'new' repos
> [name=x9c4] A pull through cache is basically an on demand provision of a remote registry. Given read permission, I would expect to be able to pull anything availabe upstream. To prevent any sort of confusion, i would never allow push to such a "proxied registry". Having write permissions, now only means I could change the parameters of the pull-through-remote.
> [name=ipanova] Yes, this pull-thru registry is read-only, meaning that noone can push content into. But we need 'write', or call it 'edit' permissions because as a result it will modify existing repository by creating new repo version. This is different from 'read' permission that will allow only consumption on the content.

### Registry 'cache' was created. It is private by default but newly created repos are public by default.

User Alice wants to pull-thru 'httpd' repo, but this repo does not exist yet in the 'cache' registry. User Alice will need 'create' model repo permission in the 'cache' registry

User Bob wants to pull-thru 'httd' repo, but this repo already exists in 'cache' registry, because just before Alice has pulled. The repo remotely has updates. User Bob will need 'write' object(or model) repo permission. 'Write' because new blob might be available and new repo-version will be created.

User Frank want to pull-thru 'httpd' repo, he has only 'read' object (or model) repo permission. He will be able to pull-thru only locally available cache, but not the new blobs if those are available at the pull moment.

Anonymous user wants to pull-thru 'httpd' repo. He has by default no permissions granted. He will be able to pull-thru only locally available cache, but not the new blobs if those are available at the pull moment.

**Note** Does it make sense for simplicity and consistency during pull operation to not distinguish between Bob and Frank and have just 'write' repo permissions.

**Note** tldr the situation changes here only changes for anonymous user

**Note** anonymous user could be granted additional permissions, e.g. 'write' object/model repo permissions, that will allow him to pull in new blobs but not create 'new' repos

### Registry 'cache' was created. It public by default and newly created repos are also public by default.

User Alice wants to pull-thru 'httpd' repo, but this repo does not exist yet in the 'cache' registry. User Alice does not need any permissions, she's treated as anonymous user.

User Bob wants to pull-thru 'httd' repo, but this repo already exists in 'cache' registry, because just before Alice has pulled. The repo remotely has updates. User Bob does not need any permissions, he's treated as anonymous user.

User Frank want to pull-thru 'httpd' repo. User Frank does not need any permissions, he's treated as anonymous user.He will be able to pull-thru locally available cache, and the new blobs if those are available at the pull moment

Anonymous user wants to pull-thru 'httpd' repo. He does not need any permissions, he's treated as anonymous user.

**Note** effectively the rbac is turned off here, any user can pull-through whether cached, or newly streamed bits, can create new repos This is an exception to corporate world. It can have reprocussions. Registry can bloat, there is no control over who pulls what.( Not fan of this scenario, we should support just first 2 with the flexibility to add perms to anon user.)

#### Vocabulary
(might need adjusting, did it by memory)

'create' model repo permission == in pulp terms repo+distribution+namespace(maybe)
'write' object(or model) repo permission == in pulp terms distribution+namespace
'read' object (or model) repo permission == in pulp terms distribution+namespace


#### Questions
Q: Should we ship with pulp by default anonymous user?
> [name=x9c4] Django has the concept of the anonymous user. It's just not persisted in the database. django-guardian came with db backen anonymous user, but it was ugly.

