Permissions on VFS resources

OpenCms allows to set permissions for users or groups at each resource in the VFS. Five different permissions are distinguished. Permissions can be inherited or overwritten. We provide you with an overview on the permission system in OpenCms. You should know the system's pecularities before assigning permissions.

Note: We speak about permissions directly attached to VFS resources here. For permissions on resource and explorer types, see here.
Related links

1 How are permissions handled in OpenCms?

Permissions are handled as ACLs (Access Control Lists) in OpenCms. This allows for fine-grained access control. For each resource rights can be set for single users, for groups and for "others" that are not listed as user or belong to one of the listed groups.

The ACLs are attached to the resource part of an VFS resource. Thus, for siblings there is just one permission set that can be set explicitely. Nevertheless, siblings can have different inherited permissions. See here for the general resource concept in OpenCms.

Fig. [permissions_schema]: How permissions are attached to resources

2 The available permissions

We describe the permissions for VFS resources. They differ from the permissions set on explorer or resource types.
read (r)

Permission to read a resource

write (w)

Permission to write a resource or add new resources in a folder.

view (v)

Permission to see a resource in the explorer (or when the VFS is mounted).

control (c)

Permission to change permissions set on a resource.

direct publish (d)

Permission to publish a resource directly. Allows to publish a resource directly, even if the user has no publish permission on the project (this is typically a role-dependent permission)

3 The interplay of permissions

Permissions have three states. For each user, a permission at a resource can be

  • explicitely or inherited (from a parent folder) set as allowed,
  • explicitely or inherited denied, or
  • unset.

To unset inherited permissions they must be overwritten ("Overwrite inherited" in the permissions dialog). This can only be done for all permissions of a user or group at once.

What happens now, if permissions for a user belonging to one or several groups has different permissions for accessing a resource?

In OpenCms denied is always stronger than allowed.

That means, if, for a resource the access is denied for a user, because it is denied for a group, the user belongs to. It will stay denied for the user, even if he is member in another group that explicitely has access to the resource, or even if access is granted directly for the user.

In such a setting it makes sense to have permissions unset. When a permission is not set for a user, directly or indirectly via a group or role, the user does not have the permission. If it is then set to allowed somehow, directly or indirectly, the permission is granted. Thus unset is like a "weak deny" that can be overwritten.

3.1 Example for the interplay of permissions

To clarify how permissions work, an example is of great help. Assume, we have a group "A" and a group "B", and a folder

  • /main-folder/

with

  • /main-folder/sub-folder/

as subfolder. Now we want all members of group A and B to have read access to /main-folder/, but only members of group A to have access to /main-folder/sub-folder/.

We set read access explicitely to "Allowed" for groups A and B on /main-folder/. Hence, as expected user that are at least in one of the groups A or B have read access to the main folder, and, via inheritance, also to /main-folder/sub-folder/.

Now we want to limit read access to the subfolder to members of group A, i.e., users only in group B and not in group A should not get access, but users that are members in both groups should.

The first thought is to deny read access for /main-folder/sub-folder/ for members of group B. But that will result in a wrong permission set: Users that are member of both groups will not be able to read resources in folder /main-folder/sub-folder/, as shown in the graphic below:

Fig. [deny_b]: Wrong solution: Denying access for group B will deny access also for users that are additionaly in group A.

A correct solution is reached by overwriting the inherited permissions on /main-folder/sub-folder/ for group B and leaving the read permission unset. Then members only in B cannot access the subfolder, but the users additionally in group A can.

Fig. [unset_b]: Correct solution: Overwrite inherited permissions for group B - all members of A get access, but members only in B do not.

4 Permissions for all others and protected areas

As you set permissions for single groups or users, you can set a kind of default permissions. These are used whenever permissions are not explicitely set for the user. As all other permissions, they can be inherited or overwritten.

Setting these rights is inparticular useful, when you want to create password protected areas. If you overwrite the inherited permissions, users where rights are not explictely set, in particular guest users that are not logged in will get a login form when trying to access such a resource with overwritten permissions.