Have you ever wondered what an ACL in Fatwire really is?
I have seen countless times, when a customer have to create a user, that he gets lost when he sees the following option:
The common reaction is just to select everything and move on...
Not a great choice in term of security.
Also, very often customers do not distinguish well ACLs from Roles.... They often think they are the same thing.
So, if you have this problem, read on...
First and before all, an ACL is just a symbolic name describing a set of permissions.
ACL are configured in the SystemACL table.
You can see existing ACLs looking into the SystemACL table itself. If you try to edit, for example, the PageEditor ACL, you will see something like this:
Now, think to this set like a set of actions you can execute against a database table.
You can read a specific row, search in it, create or update a row. Also, as a special permission, you can read the revision tracking (that is basically a log of the modifications) and edit them (removing old revisions).
So far an ACL just describes permissions you have on a single database table. But how do you associate a permission to a database table?
The secret is the SystemInfo table: give a look to the following snapshot, taken using ContentServer Explorer:
As you can see, each table is protected by an ACL. And the ACL describes what you can do with that table, if the user accessing to the table has that ACL.
So, here how actually ACL works:
First, you are identified:
Second, this is what happens:
So basically, ACL protect database tables. They are a very low level feature.
They have nothing to do with Roles, that is a CMS concept (a more elaborated and very different feature).
Here a few random notes taken looking at the standard SystemInfo configuration:
- a ElementReader can read the ElementCatalog while an ElementWriter can modify it. Writing the ElementCatalog is usually required only for developers.
- a PageReader can read the SiteCatalog while a PageWriter can modify it. SiteCatalog configures cache , so accessing it is required mostly to a system administrator (or to a developer that configures cache and permissions)
- SiteGod is present everywhere allows can do everything, so it is a very dangerous to give this permission. Normally is there only for maintenance reasons.
- xceleditor is required to access to the CMS tables, so any user in the editorial team requires it.