How OpenCms Permissions work

How Permissions Work

OpenCms Access Control Lists (ACLs) are different from most other ACLs, in that OpenCms uses a 3-stage active denial ACL. The “active denial” part is because the default permission is a type of deny.

See also the official documentation on how to set permissions.

There are 3 permission options:

1. Allow: A normal Allow, nothing special – but note that it will be overruled by a Deny on a parent.
2. [None] (nothing checked – no Allow, no Deny): A “soft” Deny; what we would normally think of as “deny”. It is “soft” by virtue of not explicitly being nor an Allow or a Deny.
3. Deny: A “hard” Deny. It will overrule any “Allow” set on a lower level in the subtree.

OpenCms respects the most restrictive permission: For example, imagine you have a person who is in both groups Administrators and Users, and the Users group has been blocked from publishing. This person will be unable to publish—even though (s)he is an Administrator! The solution: Administrators should not belong to any other groups, only the Administrators group. (This may have changed later, see Exceptions below.)

You do NOT want a “hard deny” high up in the file tree if you need to override it further down. Instead, use the “soft” Deny (no permission set explicitly, #2 above).

Default Groups

• Guest – Can view live content only.
• Webuser – (Removed in 7.0.5) Has a login, but can’t access the workplace. Used for storing member data and personalization.
• Users – Can login to the workplace, and view both the Offline (editing) and Online (live) projects. Usually has permission to read, write, view, and control (the permissions).
• Projectmanagers – Equal to Users, but additionally can publish files from the Offline (editing) to the Online (live) project.
• Administrators – Can do everything.

The Users group has write permission by default in OpenCms. To change this for your site, find your website folder (e.g. /sites/yoursite) and manually add the permissions you want for the Users group. Make sure you check “Overwrite Inherited” and “Inherit on Subfolders”, so that the permissions are inherited throughout the site. Take away the write permission by leaving it unchecked ("not allowed, not denied"). This ensures overriding is possible, e.g. granting write permission to individual people and/or resources.

With respect to rights to individual resource types, only the Administrators group (and those which have it as parent) are able to create and edit JSP pages.

Basic Permissions

You can select any combination of the following permissions, but remember that the most restrictive permissions always wins if a person is in multiple groups with differing permissions.

• READ (r) - Permission to read a resource.
• VIEW (v) - Permission to see a resource in the workplace explorer (or when the VFS is mounted).
• WRITE (w) - Permission to write a resource or add new resources in a folder.
• 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).

Exceptions

Michael Moossen from Alkacon wrote on the OpenCms Mailinglist on June 5th 2008:

... this is not a bug, it is the intended behavior. administrators are allowed to do everything, and all permission checks are ignored. This is important also to have in mind, when testing a new feature/configuration.

Additional Information

Michael Moossen from Alkacon on the OpenCms Mailinglist on December 7th 2009:

...
> Is there some kind of double usage of the +c / -c flag?
Yes, it means (almost) always control as in the docs, except in the explorer types where 'c' means create and not control, 
as just explained.
...