1.2.17 Cluster Level Privileges

Cluster level privileges are high-level privileges that control various actions performed by Exascale users.

Even though any Exascale user may be assigned such privileges, cluster level privileges are typically only assigned to cluster administration users. Other Exascale storage users typically do not require cluster level privileges, instead using privileges provided by access control lists (ACLs) associated with specific files and vaults.

Cluster level privileges are assigned by using the ESCLI mkuser or chuser commands.

There are four types of Exascale cluster level privileges, and any user may hold privileges across multiple privilege types. The following list describes the privilege types and the available privileges:

• Cluster Level Storage Privileges primarily govern the administration actions that the receiving user is allowed to perform on storage resources in the Exascale cluster. Typically, cluster level storage privileges are only assigned to users that administer the Exascale cluster. A user can hold zero or one of the following cluster level storage privileges:

  • cl_monitor: Enables the receiving user to monitor the Exascale cluster by performing list operations using ESCLI and CellCLI.

  • cl_operator: Enables the receiving user to:

    • Monitor the Exascale cluster by performing list operations using ESCLI and CellCLI.

    • Manage pool disks (create, drop, online, offline).

    • Manage software services (list, startup, shutdown, restart, delete).

    • Manage the trust store.

  • cl_admin: A set of system administrator privileges that includes all the cl_monitor and cl_operator privileges, along with all of the privileges from the other privilege types; namely:

    • All the cluster level user privileges: user_create, system_restore, and on_behalf_of.

    • All of the cluster level vault privileges specified in vlt_manage.

    • All the service privileges: cellsrv, egs, ers, syseds, usreds, bsm, and bsw.

    This privilege also enables the receiving user to:

    • Grant any privilege to any user.

    • Reset a key for any user.

    • Create and delete storage pools.

    • View extent map information.

• Cluster Level User Privileges govern the administration actions that the receiving user is allowed to perform on the Exascale cluster. Typically, cluster level user privileges are only assigned to users that administer the Exascale cluster. A user can hold zero or more of the following cluster level privileges:

  • user_create: Enables the receiving user to create new users in the cluster.

    You may choose to assign this privilege to dedicated personnel performing user administration.

  • system_restore: Enables the receiving user to restore an Exascale system.

    Do not assign this privilege to any of your Exascale users. This privilege and the accompanying operation are internal and are not used under normal circumstances.

  • on_behalf_of: A special privilege that enables the receiving user to send a request to Exascale control services (ERS) on behalf of another user.

    For example, consider a user that sends a request to ERS, which involves an action that must be performed by another Exascale service. In this case, ERS uses this privilege to forward the action to the other Exascale service on behalf of the original end user.

    Typically, this privilege is only assigned to the internal administration accounts that reside on each Exascale node.

• Cluster Level Vault Privileges are powerful data access privileges governing the actions that the receiving user is allowed to perform on all vaults and files. Typically, cluster level vault privileges are assigned to administration users that manage files in Exascale vaults.

  Cluster level vault privileges work in addition to access control lists (ACLs). To perform an action on a vault or file, a user requires the appropriate cluster level vault privilege or the appropriate ACL privilege. See Vault and File Access Control.

  A user can hold zero or one of the following cluster level vault privileges:

  • vlt_inspect: Enables the receiving user to create new vaults. The receiving user also gets complete control over files created in those vaults.

    This privilege is assigned to new users by default. However, wherever possible, you should consider removing this privilege and using specific ACL privileges instead.

  • vlt_read: Includes the vlt_inspect privileges and also enables the receiving user to list all existing vaults, display attributes for any vault, create files in any vault, list files in any vault, and display attributes for any file.

  • vlt_use: Includes the vlt_read privileges and also enables the receiving user to open any file for reading.

  • vlt_manage: Includes the vlt_use privileges and also enables the receiving user to open any file for read and write, alter any vault or file, and drop vaults and files.

• Service Privileges govern the Exascale software services that the receiving user is allowed to run. Typically, service privileges are only assigned to the internal node-specific administration accounts that reside on each Exascale node. A user can hold zero or more of the following service privileges:

  • cellsrv: Enables the receiving user to run the core Exadata cell services.

  • egs: Enables the receiving user to run Exascale cluster services (also known as Exascale Global Services).

  • ers: Enables the receiving user to run Exascale control services (also known as Exascale RESTful Services).

  • syseds: Enables the receiving user to run the system vault manager service.

  • usreds: Enables the receiving user to run the user vault manager service.

  • bsm: Enables the receiving user to run the block storage manager service.

  • bsw: Enables the receiving user to run the block storage worker service.

  • ms: Facilitates the transfer of telemetry information between Exascale RESTful Services (ERS) and the Exadata Management Server (MS).

Additionally, no_privilege is a special privilege that removes all privileges from the receiving user. When it is assigned to a user, no_privilege cannot be combined with any other privilege.