How OpenCms Permissions work

Revision as of 13:03, 1 November 2016

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.

There are 3 states for any given permission rule:

1. Allow: A normal Allow, nothing special – but note that it will be overruled by a Deny on a parent.
2. [No permission] (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), #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.

(These definitions are from the source code)

• READ (r) - The right to read the contents of a resource
• VIEW (v) - The right to see a resource in listings (workplace)
• WRITE (w) - The right to write the contents of a resource
• CONTROL (c) - The right to set permissions of a resource
• DIRECT_PUBLISH (d) - The right to direct publish a resource, even without publish project permissions

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.
...