Users privileges and access Rights - sakura-team/sakura GitHub Wiki

Sakura deals with several kinds of objects, such as databases, dataflows, etc. and several kinds of users.

User privileges

For now, there are 2 Sakura privileges:

• developer: allows a user to register new operator classes, on the web interface, or by running sakura-sandbox.
• admin: users with this privilege are able to manage the privileges of other users. This includes:
  • receiving requests of other users who want to get a new privilege
  • having specific controls displayed on the web interface to allow or deny these requests.

Note: for security reasons, it is important to carefully select user privileges. For instance, a developer can basically run any python code on a given remote sakura daemon; whereas other users can only run the code that was validated by the developers.

The web interface allows a user to ask for privileges. The current values of the privileges are displayed in the profile modal, and can take one of the four following values:

• granted (the privilege is already attributed),
• not_granted (you can ask for this privilege),
• pending (a demand as been sent, you should wait for approval).

Object access

Access to the following objects is restricted:

• datastores
• databases
• dataflows
• operator classes
• projects

Each of these objects has an access-scope tag, defining how its access is restricted:

• open means any logged in user can access (read) this object and modify (write) it.
• public means any logged in user can access (read) this object. Only users with a specific write grant (user_rw) can modify (write) it.
• restricted means any logged in user can see that this object exists (it is listed). Only users with a specific read (user_ro) or write (user_rw) grant can access (read) or modify (write) it.
• private means the object is hidden to all users except those with a specific grant.

These rules can be translated to the following table:

	open	public	restricted	private
owner	own	own	own	own
user_rw	(write)	write	write	write
user_ro	(write)	(read)	read	read
other	write	read	list	hide
anonymous	list	list	list	hide

Notes:

• own > write > read > list > hide: e.g. if you can write, you can also read and list the object.
• a list grant allows access to object metadata too.
• a list grant allows a logged in user to request the owner for a higher grant.
• only the owner is allowed to give or remove specific grants (user_rw or user_ro).
• cases marked with parenthesis should not be seen (some users got grants that the access-scope already allowed!)
• operator classes can only be private or public, and no specific user grants (user_rw or user_ro) are allowed.
• projects can only be private or public, and no specific user grants (user_rw or user_ro) are allowed.
• project pages and considered 'metadata' of the relevant project. Thus an anonymous user is allowed to read pages of a public project, even if his grant level should be list according to the above table. This is handled in the code by converting any list grant to read (for these specific objects only).

Object creation

Object creation is restricted by the following constraints:

	constraint
database creation	have a write access to the datastore
dataflow creation	be logged in (denied to anonymous users)
project creation	be logged in (denied to anonymous users)
operator class registration	have a developer privilege
operator instantiation	have a read access to the operator class

Note: datastores are missing from this table because they are not created from the interface: they are just declared on a daemon's configuration file.