Forum OpenACS Development: Permission system in needs of revisit?

Szenario One: Function based permissions.

At the moment OpenACS has object driven permissions with a given set of standard "functions" like "read,write,delete,admin". This does not work though if you need permissions based on functionality.

Example: I want to give access to a list column depending on the users permission to see this column regardless of object permissions (e.g. he has to have object permissions for the object to show up on the list, but he needs the functional permission to see the column).

Szenario Two: Profile based permissions (https://openacs.org/forums/message-view?message_id=291499).

A role of users (e.g. employees) should have access to a set of objects.

Example: All employees of company X should be able to see the profit column of all customers' projects while the customers employees should only be able to see their own projects and not the profit column

Szenario Three: Object Type permissions

A financial manager is able to edit all payments (object type) regardless of the actual object. He is not though able to see the project information for all customers (otherwise we could just give him write on /). The accountant for a company is able to see and edit all payments of a given company.

Obviously all of these could be managed with object based permissions and clever setting of context_ids and groups. But maybe we should take a look and revisit our way of handling things and allow for an extension?

P.S.: I know that PO and AIMS have solved these issues already, so it is not a "we need to do so much new coding". It is more a decision if we want these additional features and put them back into core or not.

]po[ Permissions: http://www.project-open.org/doc/intranet-core/permissions.html

XoWiki Permissions (based on rules): http://media.wu-wien.ac.at/download/xowiki-doc/#security-management

I will see what I can get for AIMS permissions.

If you avoid this situation, you can use proxy objects, and the best one to use is a relational segment, for instance 'Main Site Members' is a relational segment. You can create your own, very specialized segments and I don't think they explode the mapping tables like adding a privilege subtype. (Is this correct?).

Another great example of using a proxy object is the /admin directories. Directory access triggers special checking, so you don't have to add additional permissions to every object under /admin.

But the premise of this thread is that there is some limitation on what an object and/or permission represents. It is incorrect to say that permissions do not, and cannot apply to functions. Every application page which checks for permissions is making an assertion: if you want to apply the following functions, you need a certain permission. The fact that it is on a tcl page and not inside a procedure doesn't mean you can't do a check inside a proc.

If the check isn't inside the procedure it will be extremely difficult to force the check, and you are back to the problem with generic access to objects. If you want to access every object through the same generic interface, you are essentially ignoring the application data model. This is why I have never come up with a generic select function for query-writer: select creates new objects, either as a combination, or devoid of the context in which they are useful to the application. Specifying permissions to handle this in a generic way may not be impossible, but serves no benefit for the creating application. I have yet to see a generic interface for accessing objects which does anything interesting, unless simple display is interesting. It is no wonder that permissions would appear to be a problem in such a system (there is no design going on folks, just rows and rows of stuff).

Query-writer handles both 'profile' type permissions and 'object type' permissions. These are all bundled up in a role, so one role can span multiple objects types. A profile is like a filter. In query-writer, these can be set beyond the attribute level. For instance, you could have an object forum_message with attribute approved_p which has two values '1' or '0'. You could either disallow a role from setting this attribute, or not let them set it to '1'. You could allow a user to create the forum_message object, but disallow them from deleting it. An admin role on the same object type could delete it or set approved_p to '1'. Another overlooked use is to eliminate access to administrative columns like those going into the acs_objects table: user ip, who created or last changed the object. Generic interfaces do not easily handle the distinction.

Since it has been done, it can be done, and it didn't require any changes to the permissions system. And it is vastly more efficient to assign a user to a rel_segment and check this for each operation (just to see if they can perform the role, not individual checks) than to fill up the permission system with rows and rows of who knows what, and still have a system which can go around all of it. Ahh, heck, in query-writer you can go around it too, but it is orders of magnitude easier to use the system and not go around it.

In query-writer you can use the same set of pages and only show what a user in a particular role can do. This is possible because query-writer can produce a set of flags for each possible element in the role. These flags can be used to construct the UI, even as far as showing only select options which are allowed for the role. This particular functionality is completely independent of the query-writing functions, you could use it to construct roles and use the flags to determine if a particular set of columns was viewable by a role. Since the query-writer objects don't have to point to a database table or anything else, the object could just be a placeholder for defining roles. Since roles span objects (and objects sometimes span tables), you can construct join queries based upon the allowed columns in the different objects.

The comments found in the query-writer data model, are helpful:
http://rmadilo.com/files/query-writer/source/query-writer/

under sql/postgresql. Comments for qw_attrs is in a separate file from the table def.

Also interesting is the data which goes into the tables, this is usually called bootstrap data in the tcl directory for a package. Bootstrap data allows package developers to move query-writer data around once it has been created via the UI. But this data is so hard to read in bootstrap format, it might be interesting to see it in a slightly easier to read form (only slightly easier!):

http://whogeenie.com/qw/twist/

You can check out the WSDL to get a list of object types in the enumeration:

http://whogeenie.com/qw/twist/?WSDL

(The TWiST config is at index.txt)

I've also put a listing of the nsv arrays at:

http://whogeenie.com/qw/twist/nsv.html

The nsv arrays contain all of the information needed to run query-writer, none of the data in the query-writer tables are used during runtime, just loaded at startup.

But what should I do with create? Here I need the proxy object, because I cannot give create permissions on a not yet created object. We could argue to say that "if you have create permissions on the context_id then you are allowed to create the object". But is this right? And wouldn't I still have to check if I am allowed to have write permission on the object_type?

With a role, you don't give role permissions to the individual objects, just the object type, so there is nothing different with create (in query-writer this is the 'new' operation). But another point to keep in mind with roles is that the not only filter the base objects, but the role can span multiple object types.

Otherwise, in order to allow users to serve in a role, you would have to assign multiple permissions. This could get confusing as roles may overlap, and if you remove a user from a role, you might damage the other role configuration.

Here I'm just speaking in general about a role and how it differs from objects and permissions on objects. In other words, think of roles as something layered on top of the main objects of interest. It is a description of what you can do, and a container for allowing users to assume a particular role.

In query-writer, I have one default admin group. It doesn't require any extra permissions, the user has to belong to the admin rel_segment (for the site). Even then, you could use a separate admin rel_segment to create a less expansive admin role. What I have found works best is for each package to configure their own roles which don't extend beyond the objects in that package, however, these could include objects which were initially created by another package. So for a particular package, the role assignment happens once for each user (for each role they can assume). For most applications, you don't even need to do this, the defaults work for an admin and regular user of the package.

My experience is that it vastly improves performance. I am aware of the consequences if you are not using the TCL API to insert/delete/change permission records and I make sure that this condition is met (talking of which, how could we do an automated test that checks if people are using custom DB calls to change permissions?)

My question though: It uses util_memoize. If I understood Don, he would like to get away with util_memoize in general and use ns_cache directly. Not entirely sure how / why, but for permission caching I was wondering if we should have a separate cache? Is there any downside I am not aware of?

The one I can think of is the fact that I need to (re-)write cluster wide permission flushing for permissions. Anything else ?

There is a small bug in permission::permission_p_not_cached: the unused non-positiional argument "-no_cache" should be most probably removed.

The privileges read/write/admin have no fixed meaning with regard to what can be done to a particular object. But they are hierarchical. Admin implies read/write.

However, additional privileges are difficult to maintain, they have to be granted individually, and the lead to an explosion in the size of internal mapping tables.

I would also wonder if using a privilege on a particular object to is really what you want to use when deciding to create a subobject.

In fact, this idea is only a little improved over Malte's suggestion to make acs object types into objects.

Here is the problem: privileges granted on a particular object, like read, write, admin apply to manipulation of that object. That is, the data in a row of the object types table. Otherwise you are making an exception of how object privileges are used. Turning object types into objects and assigning permissions on these objects is a complete abuse of the idea of permissions: they apply to the objects themselves (the type object).

The concept of proxy object and how it should be used in this case is confusing. I don't think I do a good job of explaining it. There are two parts.

First the rel_segment places a user in a particular segment of a group. A group is a party, a party can own things. A party is the 'container' you ultimately need for application data, but applications are complex, so you need a complex party: a group with segments of users, roles.

When you ask a role type question, you are looking at membership, not permissions. Membership is the container for the role, but it isn't a permission question.

Privileges on a particular object comes after you look at if and how a particular user can interact with objects of that type.

However for creating new objects which exist in a hierarchy, it is common to require either admin or write privilege on the context_id for the object, sometimes this is the same as a parent_id, but in any case, permission checks should be done for any object_ids used in an object. This is confusingly similar to a role, but has a completely different purpose.

One final distinction between privilege and role. If you do use 'create' on the parent object to imply the right to create children, then you are stuck wih the need for another type of create for each role. This is exactly what you don't want. It doesn't help the object/permission system to add privileges.