Permissions questions of the day

1. I’ve been perusing the list of permissions at
http://svn.modxcms.com/docs/display/revolution/Permissions+-+Administrator+Policy

Just for kicks, I decided to open the Administrator Access Policy in my Revo b5 installation and compare. My assumption was that every permission in the documentation would be in the Administrator policy. But I found that there were several permissions in the documentation that weren’t in the Admin policy, and vice versa. Is this simply a matter of the documentation being out-of-sync with the latest beta? Or what?

2. What the heck are these permissions, anyway? I can open any Access Policy and add a new permission called anything I want... but what good does that do me? Is there really a hypothetical situation where an end user would need to create a custom permission for something? If so, how would they go about making it useful?

3. I’m dangerous enough to have figured out that these permissions live in the table ’modx_access_permissions’. But I was expecting to find a table where the permission name was a unique key... but instead each record is a permission tied to a specific policy. I understand the usefulness of the table as it stands, but it feels like there should be some other table with one entry for each permission... essentially the list I linked to above.

I’m not trying to suggest that your structure is wrong and I’m right... I don’t put much stock in my own limited understanding of how databases "ought to be". I’m just trying to gain some insight into the way these permissions work, and how their existence or non-existence in a given Access Policy actually allows/prevents a user from performing a given task. Anything I can learn toward that end will I think help a great deal.

Quote from: jrotering at Mar 10, 2010, 09:54 AM

Just for kicks, I decided to open the Administrator Access Policy in my Revo b5 installation and compare. My assumption was that every permission in the documentation would be in the Administrator policy. But I found that there were several permissions in the documentation that weren’t in the Admin policy, and vice versa. Is this simply a matter of the documentation being out-of-sync with the latest beta? Or what?

The docs are probably more in-sync with SVN, which has a few new permissions.

2. What the heck are these permissions, anyway? I can open any Access Policy and add a new permission called anything I want... but what good does that do me? Is there really a hypothetical situation where an end user would need to create a custom permission for something? If so, how would they go about making it useful?

Oh, yes. For example, custom Extras (3PCs, or 3rd Party Components) can use Permissions to add their own security schemes.

For example, let’s say you had a 3PC that managed financial accounts. You could add permissions called ’view_account’, ’save_account’, etc, add an ’AccountPolicy’, and use $modx->hasPermission in your 3PC code to restrict access to certain parts of your 3PC via the permission scheme. This gives you incredibly fine-tuned access permission schemes at your fingertips, built into the core of Revolution.

3. I’m dangerous enough to have figured out that these permissions live in the table ’modx_access_permissions’. But I was expecting to find a table where the permission name was a unique key... but instead each record is a permission tied to a specific policy. I understand the usefulness of the table as it stands, but it feels like there should be some other table with one entry for each permission... essentially the list I linked to above.

TBH, we debated this for quite a while, but found that we’d rather have permissions be policy-specific rather than global. There really was no benefit to making Permission keys global, and it eventually would cause problems with conflicts across different policies. So, we’re using Policies as a sort of ’namespacing’ for Permissions.

Good questions!

Quote from: jrotering at Mar 10, 2010, 09:54 AM

1. I’ve been perusing the list of permissions at
http://svn.modxcms.com/docs/display/revolution/Permissions+-+Administrator+Policy

Just for kicks, I decided to open the Administrator Access Policy in my Revo b5 installation and compare. My assumption was that every permission in the documentation would be in the Administrator policy. But I found that there were several permissions in the documentation that weren’t in the Admin policy, and vice versa. Is this simply a matter of the documentation being out-of-sync with the latest beta? Or what?

Yes, we have added new permissions since the last release.

Quote from: jrotering at Mar 10, 2010, 09:54 AM

2. What the heck are these permissions, anyway? I can open any Access Policy and add a new permission called anything I want... but what good does that do me? Is there really a hypothetical situation where an end user would need to create a custom permission for something? If so, how would they go about making it useful?

You can add custom permissions for your custom applications; this is meant for developers to work with when developing components.

Quote from: jrotering at Mar 10, 2010, 09:54 AM

3. I’m dangerous enough to have figured out that these permissions live in the table ’modx_access_permissions’. But I was expecting to find a table where the permission name was a unique key... but instead each record is a permission tied to a specific policy. I understand the usefulness of the table as it stands, but it feels like there should be some other table with one entry for each permission... essentially the list I linked to above.

Permissions are free-form in attribute-based access control systems; they may mean different things in different ACL’s (an ACL being a distinct set of relationships between a specific kind of target object you want to apply a policy to, i.e. Context ACLs apply to Contexts, Resource Group ACLs apply to Resource Groups, etc.). We needed different descriptions for the same key in different Policies.

Quote from: jrotering at Mar 10, 2010, 09:54 AM

I’m not trying to suggest that your structure is wrong and I’m right... I don’t put much stock in my own limited understanding of how databases "ought to be". I’m just trying to gain some insight into the way these permissions work, and how their existence or non-existence in a given Access Policy actually allows/prevents a user from performing a given task. Anything I can learn toward that end will I think help a great deal.

This is based on a tried and tested pattern of access control known as Attribute-Based Access Control or ABAC. Feel free to ask more questions; it helps everyone better understand the system and helps us better document what is difficult to understand.

Thanks for the responses. Discovering $modx->hasPermission is itself a tremendous revelation. I just spent two minutes grepping ’hasPermission’ on the files in my install directory, and I could feel my brain getting slightly larger. Likewise on the explanation of free-form permissions being inherent to the ABAC approach.

I definitely think that this is one area that could use a lot more documentation, both from the core team and the user community, and geared toward all different skill levels. I’ll try and do my part with a dummy-level tutorial once I get my head a little further around some of this stuff.

http://bobsguides.com/revolution-permissions.html