Feature #449
Create a module that sets and checks permissions
Status: | Closed | Start date: | 04/28/2011 | |
---|---|---|---|---|
Priority: | Medium | Due date: | ||
Assignee: | - | % Done: | 0% |
|
Category: | Pithos | Spent time: | - | |
Target version: | - |
Description
We need Read, Write and ModifyACL permissions that can apply to either a user or a group. Permissions need to be hierarchical: permissions of the parent apply to all the children too (unless overridden).
Since we have a pseudo-hierarchy we will probably have to use a prefix based inheritance ("photo" is a parent of "photos"). A possible interface could be something like the following:
def set_permission(path, user_or_group, read=False, write=False, modify=False): return def delete_permission(path, user_or_group): return def get_permissions(path): """Returns a list of tuples (USER_OR_GROUP, READ, WRITE, MODIFY, LOCAL). LOCAL is a boolean value to differentiate between permissions that have been set for this path and permissions that apply due to inheritance. """ return [] def check_permission(path, user_or_group, perm): """`perm` can be one of "read", "write" and "modify". This method will check `path` and all its parents and decide if `user_or_group` is allowed to perform `perm`. """ return False
This module will be used by the backends.
Associated revisions
Updated permissions support.
- Allow deleting/clearing permissions.
- Report inheritance via 'X-Object-Shared-By' header.
- Enforce permissions.
Refs #449
Updated permissions support.
- Allow deleting/clearing permissions.
- Report inheritance via 'X-Object-Shared-By' header.
- Enforce permissions.
Refs #449
Add account groups, merge into sharing. Fix tests.
Refs #449
Add account groups, merge into sharing. Fix tests.
Refs #449
- Account groups.
- Container policies (not enforced for now).
- Document sharing/permissions.
Refs #449
- Account groups.
- Container policies (not enforced for now).
- Document sharing/permissions.
Refs #449
Return the conflicting path in the reply, when refusing to change permissions because of a conflict.
Refs #449
Return the conflicting path in the reply, when refusing to change permissions because of a conflict.
Refs #449
History
#1 Updated by Antony Chazapis over 12 years ago
Permissions are not the only "inherited" attribute in Pithos. Consider also "shared", "deleted" and maybe others in the future. Assuming generic metadata handling in the backend, we could easily implement permissions from another module (access control module) that indeed follows some API like this, and communicates with the backend via generic put/get metadata calls.
The backend would need a mechanism to retrieve a hierarchy (pseudo, given the namespace structure), along all metadata keys specified in a mask, using a function like: list_object_tree(user, container, name, prefix, delimiter, meta_mask).
#2 Updated by Antony Chazapis about 12 years ago
- Status changed from New to Resolved
- Assignee set to Antony Chazapis
- Target version set to 0.4
We have decided to impose a prefix-based inheritance scheme, although with no overlapping permission directives.
#3 Updated by Antony Chazapis about 12 years ago
- Status changed from Resolved to Closed
- Assignee deleted (
Antony Chazapis)
#4 Updated by Vangelis Koukis over 10 years ago
- Project changed from Pithos to Synnefo
- Target version deleted (
0.4)
#5 Updated by Vangelis Koukis over 10 years ago
- Category set to Pithos