Forum OpenACS Development: Re: Permission system in needs of revisit?
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.
With the listbuilder example given above, this is solved if Dave's changes with regards to listbuilder views (or stored settings) makes these objects as planned. Then you can easily work around the "has permission to see column XYZ" by giving him access to the view. Which probably covers most szenarios (as you usually want to limit certain columns or group of columns for access).
For other functional permissions I am only curious about a naming convention then, which makes it easy for the admin interface to assign new types of permissions.
Profile based permissions I will first dig deeper into query rewriter to be able to understand the posting. Hopefully at the end I can come up with a document on how to use permissions effectively.
Now, Don, as per your comment, sadly I am usually confronted with websites that have these many objects and parties, if not even more. Add to that the fact that people do not understand the permission system correctly and you suddenly end up with 750.000 entries into acs_permissions per day. This being said, it is still remarkable how fast the permission querying works (okay, up to 1.5 seconds for the query, but what do we have permission caching for). It is only slow on delete (when you remove a permission). Therefore, in my opinion, the goal should be to limit the entries to the permissions table as good as possible (in the 750.000 example I did this by "correct" inheritance) and I will take a look at the approaches suggested by Tom for the above mentioned howto / best practice, permissions for dummies text.
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.
I am now faced with the situation that I need to give permission to create various object types through an external interface. The only requirement is that the users can create, write and delete (for the sake of discussion) "tasks, projects,files,comments". Write and delete is a piece of cake, though it implies to either be stuck with a lot of entries into the permission table or to group them into proxy objects / roles in the code.
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?
This being said, it can all be done with the existing permission system and making object_types objects has nothing to do with it. But I am still unsure how "create" should behave 😊.
Now to something more interesting:
Assuming object_types are objects (or I use rel_segments), if I have read access to an object_type (rel_segment) I have access to the object of that type if I have access to the context_id. Meaning: If I have read access on tasks in general, I am able to view a task if I have read access on the project.
I will ponder about this a little bit more while working out how to map an external permission system (meaning remote, not in OpenACS) to the generic way of permissions in OpenACS so I do not have to touch every part of OpenACS to get those external permissions working and do not have to query the external permissions on every page but can "cache" them in the OpenACS permission system.
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.