GreyCat relies on a Role Based Access Control (RBAC) to enforce fine-grain security controls.

Permissions are simply rights to read or write within a particular resource.

Permission is then associated with the user through the notion of roles.

Roles are simply collections of permissions associated with various Users.

One user can only be linked to a single Role.

GreyCat standard library already defined a few:

Function permissions decorator

Permission must be declared in a decoarator of at least of function in the program.

The following snippet illustrates the syntax:

native fn modules(): Array<ModDesc>;

Now the function modules can only be called by a user who has the permission api in his token.

Several permissions can be composed in the same decorator, and then the semantic applied is a OR, as follows:

@permission("super", "normal")
fn test(){
        // normal user
    } else {
        // super

The test can now be applied by a users which has either super or normal permission.

In case the permission influences the result, it can be dynamically checked by the helper hasPermission.

The same helper exists in SDK like TS for WebApplication that need

    // call rpc

Permission is therefore the checkpoint that developers should rely on for adaptative applications.

Roles should only be used for configuration and never for dynamic checks!

Standard defaults roles

By default the standard library defines some roles that are pre-configured to ease all standard usages.

Default init of roles

Most applications need to define in addition to standard roles their permissions. To do so, the type UserRole from the runtime module has two static methods all() and get(), see the following example:

fn main() {
  if (init == null || !init) {
    for (_, role in UserRole::all()) {
      if ( == "admin") {
      } else if ( === "user") {