Entities and Access Control

Security enforcement in SciDB takes place with respect to abstract objects called entities. Currently there are only two types of entites: namespaces and the database as a whole.

Access control policies are expressed internally in terms of (role, permissions, entity) tuples. Informally, an access control tuple means that if a user has been granted a certain role then they have permissions to access an entity. Individual users belong to one or more roles. When a user logs in, she acquires the union of all permissions-on-entities implied by her role memberships. (This differs from earlier SciDB versions, in which a user could only assume a single role at a time and had to manually switch between roles.)

Namespaces are named entities described below. The database-as-a-whole entity is a special, unnamed entity for expressing administrative access permissions. It is used to implement the special roles admin and operator. Members of these special roles, along with the pre-configured scidbadmin user account, are administrative users. All other user accounts are non-administrative users.

Namespaces

In secure mode, SciDB stores array data in protection domains called namespaces. Namespaces are containers for array data, just as directories are containers for files. Unlike directories, namespaces cannot be nested. SciDB connection sessions have a "current namespace" that is similar to a Linux shell's current working directory. You can change your current namespace to access arrays stored there in the usual way, or you can access arrays in any arbitrary namespace by using a qualified array name. For example, if your current namespace is called ns1 and you need to access an array called SAMPLES in a namespace called sensornet, you can use the qualified array name sensornet.SAMPLES in an AFL query to read or write that array. Alternatively, you can use the /wiki/spaces/SD/pages/242778276 operator to move to the sensornet namespace and then use the unqualified name SAMPLES to access the array.

The `public` Namespace

When security mode is first enabled, any array data previously stored in the system appears in a namespace called public. The public namespace is similar to the Linux directory /tmp . All users in the system can read and write arrays in public . Each time you connect to SciDB, your current namespace is set to public .

Roles and Namespace Permissions

The database administrator /wiki/spaces/SD/pages/241664119 and /wiki/spaces/SD/pages/242974828, /wiki/spaces/SD/pages/242843809, and /wiki/spaces/SD/pages/242811019. Permissions are encoded as strings. For namespaces, permission strings may contain the following code letters:

Code	Permission	Remarks
c	create	Role can create arrays in the namespace.
r	read	Role can read array data in the namespace.
l (ell)	list	Role can list the arrays contained in the namespace.
u	update	Role can update pre-existing arrays in the namespace.
d	delete	Role can remove arrays in the namespace.

For example, if role analyst has rl permission for namespace satellite_images, users granted the analyst role can list and examine all array data in the namespace, but cannot alter the namespace data in any way. Or, if role uploader has c permission for namespace sensornet, users granted the uploader role can only add new arrays to the namespace. They cannot see what's in the namespace, or even read back data they just loaded.

File I/O Restrictions

The AFL I/O operators /wiki/spaces/SD/pages/242811029, /wiki/spaces/SD/pages/242811079, and /wiki/spaces/SD/pages/242745452 and the I/O operators in the accelerated_io_tools plugin read and write data files on SciDB server hosts. In security mode, non-administrative users are quarantined from each other. They can only read and write data files in per-user directories, or to a list of absolute directory paths configured by an administrator. For details, see the File I/O Restrictions page.

Browser not supported