Skip to main content

Privileges and Permissions

Permissions allow you to perform some action, such as reading or writing data, or using a tool. Permissions are associated with resources, forming privileges. This model allows a user to perform a particular action in relation to a particular resource.

How Privileges Work

A privilege associates a resource with a permission, so that a role that holds the privilege can perform a particular action, such as read or write to a database or use an application. The possible permissions are:

  • Read — View (but not change) the contents of a resource, such as in a database

  • Write — View or change the contents of a resource, such as in a database

  • Use — Run or otherwise employ an executable program or tool, such as an application or a Caché service

The meaning of each permission depends on the resource with which it is used. Permission names can appear as the full word or the first letter of the word; their names are not case-sensitive.

Public Permissions

For each resource, permissions can be designated as Public. Effectively, this is equivalent to all users holding that permission on the resource. For example, if the %Service_CacheDirect:Use privilege is Public, then any user can connect to Caché using the Caché Direct technology. Similarly, if the %DB_SALES:Read privilege is Public, then any user can read from any database protected by the %DB_SALES resource. This does not, however, enable all users to write those databases because (in this example) the %DB_SALES:Write privilege is not Public.

The following database privileges are Public by default:

Default Public Privileges
Resource Permission

Checking Privileges

Caché provides a method, $SYSTEM.Security.Check, to check on privileges held by the current process. Its one-argument form lists what privileges the process holds on a particular resource; its two-argument form returns whether or not the process holds privileges for a particular resource.

The one-argument form returns a comma-delimited list of the permissions held by the process on a resource. For example:


returns READ,WRITE if the process holds Read and Write permissions for %DB_Samples. The permission names are always returned as full words in uppercase letters. The function returns an empty string if the process holds no permissions on the resource.

The two-argument form returns True or False (1 or 0) to indicate whether the process holds a specific privilege. For example:

$SYSTEM.Security.Check("%DB_Samples", "WRITE")

returns 1 if the process holds the Write permission on the %DB_Samples resource.

You can also call the function with a list of permissions, such as:

$SYSTEM.Security.Check("%DB_Samples", "WRITE,READ")

It returns 1 if the process holds all of the requested permissions and 0 otherwise. You can also simply use the first letter of the privileges to be checked:

$SYSTEM.Security.Check("%DB_Samples", "W,R")

The method has the following general behaviors:

  • The method always returns 1 for a public resource privilege, whether or not the process explicitly holds that privilege.

  • Permission names are not case-sensitive.

  • Permission names can be fully spelled out, as in the example above, or abbreviated by their first character. Also, permission names are not case-sensitive. Thus, “WRITE,READ”, “W,R”, and “R,Write” are equivalent.

When Changes in Privileges Take Effect

Caché maintains a persistent database of the security settings. When Caché starts, it extracts this information and places it into a segment of shared memory that allows quick access to the consolidated settings. While a process is executing, it maintains its own per-process cache of the privileges it has been granted. This is updated as new privileges are needed (and authorized).

Editing roles, privileges, and so on makes changes to the persistent copy of the information. This becomes visible to users or applications the next time they are subsequently authenticated.

FeedbackOpens in a new tab