App Permissions

In order to project user privacy and to make reproducibility guarantees feasible, apps are by default heavily restricted in what data they can read and write. Some apps, such as data management tools or apps that make use of external online resources, may wish to request relaxation of these restrictions.

As a user, you will be notified of these additional permissions before installing the app; in addition, administrative policy for an organization may disallow the use of apps that possess certain permissions.

By default, when an app is run, the following happens:

• Any input objects provided by the user to the job are cloned into the job's temporary workspace.

• When running, the job has CONTRIBUTE (i.e. read and write) access to its temporary workspace, and nothing else. The job cannot access the internet.

• When the job finishes, all of its outputs are cloned back into the job's project context (the project from which the job was run).

That is, an app cannot read any objects except its input objects, it has no other access to the "outside world", and it only has the power to create new objects in the project context; it cannot modify or remove any existing objects in the project context, nor can it create objects in any other project.

Apps may request the following permissions in order to relax the usual rules:

• Access to the Internet or to selected hosts on the Internet: The execution environment permits the job to connect to hosts on the internet, or to specific hosts (which may be specified as hostnames, hostname wildcards, or network masks). Note that if the Forwarding Job Logs to Customer's Splunk feature is enabled, jobs without network access will still send job logs to the customer's Splunk endpoint, resulting in egress charges.

• Direct access to the project in which the app was launched: The job may directly manipulate its project context. It may delete or modify existing objects or create objects that are not explicitly enumerated among the job's outputs. The job may use any permission up to whatever access level the user actually has on the project, or it may be restricted to a lower access level (for example, only receiving CONTRIBUTE access even if the user has ADMINISTER on the project).

• Direct access to all projects: The job may directly manipulate ANY project that the user has access to. The job may use any permissions up to whatever access level the user actually has on each project, or it may be restricted to a lower access level (for example, only receiving CONTRIBUTE access to each project even if the user has ADMINISTER on some projects).

• Developer permissions: The job may manipulate any app (e.g. creating, updating, or publishing apps) that the user has permission to manipulate, or create a new app on behalf of the user. (These permissions are broken out separately because apps do not live in projects and therefore access to them cannot be given by granting access to any project.)