User Tools

Site Tools


arch:roles-permissions

Roles and permissions

The permissions granted to some user in a CONFINE testbed depend on the roles associated to that user.

Roles

The testbed roles of a user are implicitly defined by the authentication state of the user and its relationships with other objects as defined in the registry. These roles apply to all interactions of the user with the testbed. The following testbed roles are defined:

Anonymous user
Not authenticated or marked as not active. This is the kind of access used by nodes and external services.
Registered user
Authenticated and active.
Superuser
Authenticated and active, marked as superuser.
Host H owner
Authenticated and active, related with host H as its owner.
Group G member
Authenticated and active, related with group G.

In contrast, the group roles of a user are explicitly defined by the enablement of its corresponding role flags in a given group. These roles only apply to the interactions of the user with the objects belonging to that group. The following testbed roles are defined:

Group G group administrator
Authenticated and active, related with group G with group administrator role enabled.
Group G node administrator
Authenticated and active, related with group G with node administrator role enabled.
Group G slice administrator
Authenticated and active, related with group G with slice administrator role enabled.

Permissions

The following permissions are assigned to each of the roles described above. Some of the actions allowed by these permissions are restricted so that the registry is kept in a consistent state (e.g. the only group administrator of a group cannot be removed from it). In these cases the permission is marked with WML (with meaningful limitations).

  1. Anonymous user
    • List and read everything (except e-mails, telephones and other sensitive information which appears as <hidden>).
  2. Registered user = anonymous user +
    • Reveal own hidden fields.
    • Update own fields (except activation and superuser flags) (WML).
    • Remove self (WML).
    • Create host (becomes its owner), update and remove it.
    • Create group (becomes its group administrator).
  3. Group G member = registered user +
    • Remove self as group G member (WML).
  4. Group G slice administrator = group G member +
    • Create, update and remove slices and slivers in group G (WML) if slices are allowed in the group.
    • Log into slivers of slices of group G as root (as described in Out-of-band remote access to CONFINE slivers).
    • Drop slice administrator role on group G.
  5. Group G node administrator = group G member +
    • Create, update and remove nodes in group G (WML) if nodes are allowed in the group.
    • Drop node administrator role on group G.
  6. Group G group administrator = group G slice administrator + group G node administrator +
    • Update group G info (except slices and nodes allowance) (WML).
    • Add/remove registered users as group G members.
    • Change roles of members in group G (WML).
    • Remove group G (WML).
  7. Host H owner = registered user +
    • Update and remove host H (WML).
  8. Superuser
    • Everything (WML, non-meaningful changes require direct access to the database).

Please note that there is no permission for logging into nodes as root, so there is no way for the testbed registry to dictate who can act as the root user of a node. This is done on purpose to prevent a cracked registry server from injecting the attacker's credentials into nodes, which would effectively turn the whole testbed into a botnet. On the contrary, the provision of root credentials to a node must be done by external means by someone who already has root access to the node.

arch/roles-permissions.txt · Last modified: 2015/09/02 08:54 by ivilata