BASE is a multi-user environment that supports cooperation between users while protecting all data against unauthorized access or modification. To make this possible an elaborate permission system has been developed that allows a user to specify exactly the permission to give to other users and at the same time makes it easy to handle the permissions of multiple items with just a few interactions. For this to work smoothly there are a few recommendations that all users should follow. The first and most important recommendation is:
![[Important]](../../gfx/admonitions/important.png) |
Always use a project! |
|---|---|
| By collecting items in a project the life will be a lot easier when you want to share your data with others. This is because you can always treat all items in a project as one collection and grant or revoke access to the project as a whole. |
Whenever you try to create or access existing items in BASE the core will check that you have the proper permission to do so. There are several permission levels:
- Read
-
Permission to read information about the item, such as the name and description.
- Use
-
Permission to use the information. In most cases this means linking with other items. For example, if you have permission to use a protocol you may specify that protocol as the extraction protocol when creating an extract from a sample. In the case of plug-ins, you need this permission to be able to execute them.
- Annotate
-
Permission to add, update or delete annotations on an item. In addition to this permission, Use permission is required on the annotation type.
- Write
-
Permission to change information about the item.
- Delete
-
Permission to delete the item.
- Change owner
-
Permission to change the owner of an item. This is implemented as a Set owner function in the web client (Section 5.3.6, “Change owner of items”), where you can change the owner of items that you have permission to do so on.
- Change permissions
-
Permission to change the permissions on the item.
- Create
-
Permission to create new items. This permission can only be given to roles.
- Deny
-
Deny all access to the item. This permission can only be given to roles.
![[Note]](../../gfx/admonitions/note.png) |
Note |
|---|---|
| A user's permissions need to be reloaded for the permissions that have been changed should take effect. This is done either manually with the menu choice or automatically next time the user logs in to BASE. |
There are several ways that permission to access an item can be granted to you. The list below is a description of how the permission checks are implemented in the BASE core:
-
Check if you are the root user. The root user has full permission to everything and the permission check stops here.
-
Check if you are a member of a role that gives you access to the item. Role-based permissions can only be specified based on generic item types and is valid for all items of that type. The role-based permissions also include a special deny permission that prevents a user from accessing any item. In that case, the permission check stops here.
-
Check if you are the owner of the item. As the owner you have full permission to the item and the permission check stops here. This step is not done for items that doesn't have an owner.
-
Check if you have been granted access to the item by the sharing system (cf. Section 5.3.5, “Share items to other users”). The sharing system can grant access to individual users, groups of users and to projects. We recommend that you always use projects to share your items. This step is not done for items that can't be shared.
-
Some items implement special permission checks. For example:
-
News: You always have read access to news if today's date falls between the start and end date of the news item.
-
Groups: You have read access to all groups where you are a member.
-
Users: You have read permission to all users that share group membership with, excluding the Everyone group. When a project is active, you also have read permission to all users that are members of that project.
There are more items with special permission checks but we do not list those here.
-
Another aspect of the permission system is that plug-ins may also have permissions of their own. The default is that plug-ins run with the same permissions as the user that invoked the plug-in. Sometimes this can be seen as a security risk if the plug-in is not trusted. A malicious plug-in can, for example, delete the entire database if invoked by the root user.
An administrator can choose to give a plug-in only those permissions that is required to complete it's task. If the plug-in permission system is enabled for a plug-in the default is to deny all actions. Then, the administrator must assign permissions to the plug-in. There are two variants:
-
A permission can be granted regardless of if the user that invoked the plug-in had the permission or not. This makes it possible to develop a plug-in that allows users to do things that they normally do not have permission to do directly in the web interface.
-
A permission can be granted only if the user also has the permission. This is the same as not using the plug-in permission system, except that unspecified permissions are always denied.
|
Note |
|---|---|
| Plug-in developers can supply information about the wanted permissions making it easy for the administrator to just check the permissions and accept them with just a single click if they make sense. See Section 22.1.6, “Plug-in permissions” for more information. |