Main permissions

DSS uses a groups-based model to allow users to perform actions through it.

The basic principle is that users are added to groups, and groups have permissions on each project.

Per-project group permissions

On each project, you can configure an arbitrary number of groups who have access to this project. Adding permissions to projects is done in the Project Settings, in the Security section.

Each group can have one or several of the following permissions. By default, groups don’t have any kind of access to a project.

Admin

This group may perform any action on the project, including:

  • change the permissions of the project
  • change the project owner

This permission implies all other permissions.

Read project content

This group may see the Flow, access the datasets, read the recipes, … More generally speaking, this group may read every configuration and data in this project.

This permission implies the “Read dashboards” permission

Write project content

This group may read and write every configuration and data in this project. This includes the ability to create new datasets, recipes, …

This also includes the ability to run all jobs in this project.

Note

This permission is the “default” permission that you may want to give to your data team.

This permission implies the “Read project content”, “Read dashboards”, “Run scenarios” and “Write dashboards” permissions

Export datasets

This group may click on the “Download” button to retrieve the content of a dataset.

Warning

Disabling this permission removes the most obvious way to download whole datasets, but through various means, users who have at least “Read project content” will still be able to download datasets.

If you absolutely want your users not to be able to retrieve the full content of datasets, do not give them access to the project.

Run scenarios

This group may run scenarios. They may not run jobs that are not part of a scenario. Only scenarios that have a “Run As” user may be run by users who only have this permission.

This permission is generally not very useful without the “Read project content” permission.

Read dashboards

This group may read dashboards that have been created. They may not modify anything. They can only read dashboard insights that use project objects that have been shared with them using Dashboard authorizations.

Write dashboards

This group may create their own dashboards, using the project objects that have been shared with them using Dashboard authorizations.

This permission implies “Read dashboards”.

Moderate dashboards

This group may modify all project dashboards, including those that they have not created. They can also “Make public” and “Make private” dashboards, so that they appear or not on all user’s dashboards list.

This permission implies “Write dashboards” and “Read dashboards”.

Manage dashboard authorizations

This group may modify which objects of the project are usable by dashboard-only users through the Dashboard authorizations.

This permission is generally not very useful without the “Read project content” permission.

The main use case for this permission is the following:

  • A group of analysts and data scientists creates a Flow
  • The data is of medium sensitivity so all dashboard users could use any of the Flow
  • However, the dashboard users must not be able to break or modify the Flow
  • Thus, the dashboard users (or a subgroup of them) has this permission to gain access to source datasets

Manage exposed elements

This group may modify which objects of the project are available in other projects through the Exposed objects.

This permission is generally not very useful without the “Read project content” permission.

The main use case for this permission is the following:

  • A group of analysts and data scientists creates a Flow
  • The data is of medium sensitivity so all or some DSS users should be able to reuse it on other projects
  • However, the other projects’ users must not be able to break or modify the Flow
  • Thus, a group of other porject’s users has permission to go in the project, and “pick” datasets to use in other projects.

Project owner

In addition to the per-group access, each project has a single user who “owns” the project. Being the owner of a project does not grant any additional permissions compared to being in a group who has Administrator access to this project.

This owner status is used mainly to actually grant access to a project to the user who just created it.

Global group permissions

In addition to the per-project permissions, groups can also be granted several global permissions that apply to all DSS.

These permissions are configured in the settings screen of the group.

  • DSS Administrator: if the group has administrator access, members of the group may perform any action on DSS. DSS administrators are implicitely administrators of all DSS projects and may access project even without being granted access through a project-group grant.
  • “Manage UDMs”: members of this group may create instance-wide user-defined meanings, which will be accessible and usable by all DSS projects.
  • “Create projects”: members of this group may create new projects on this DSS instance. This includes the ability to create tutorials, import sample projects or import project archives.
  • “Write safe code”: this permission allows the members of the group to write code which will run with impersonated rights. This permission is only available when Multi-user security is enabled.
  • “Write unsafe code”: this permission allows the members of the group to write code which will be executed with the UNIX privileges of the DSS UNIX user.

Write unsafe code: details

For more information about regular vs multi-user security, see Multi-user security

Regular security mode

In regular security mode, DSS runs as a single UNIX user. Therefore, all code which is written through the interface, and which executes locally, runs with the permissions of said user.

This includes notably:

  • Python and R recipes
  • Python and R notebooks
  • PySpark and SparkR recipes
  • Custom Python code in preparation recipes
  • Custom Python code in machine learning models

No user (even with the Data Scientist profile) may write such code if they are not granted the “Write unsafe code” permission.

It is important to note that since the DSS Unix user has filesystem access to the DSS configuration, a user who has “write unsafe code” permission is able to alter the DSS configuration, including security-related configuration (in other words, a hostile user with these privileges is able to bypass DSS authorization mechanisms)

Multi-user-security mode

In multi-user security mode, most of the above mentioned code runs with end-user permissions. The “write unsafe code” permission thus only applies to a few bits of code which don’t have end-user impersonation capabilities.

  • Write custom models in machine learning (TODO TODO TODO)
  • Write custom partition dependency functions
  • Write Python UDF in data preparation

Multiple group membership

Users may belong to several groups. All permissions are cumulative: being a member of a group who has a given permission grants it, even if you are also member of a group who doesn’t have said permission.

DSS does not have negative permissions.