Forum OpenACS Development: Ideas for using groups to minimize custom permission

Maybe the standard group membership UI? (That could of course be improved, but that's another topic)

This will create a bunch of 'special groups', per subsite I guess, no? Where and how will they be maintained and identified?

That is can one user have two different membership relationships with the same group.

First, you frequently want to grant admin on all *content* of an object, e.g. all bugs in a bug-tracker, without granting admin on the bug-tracker itself. Or admin on all forums and threads, without granting admin on the forums package itself.

Also, the 'grant admin on all news items' has come up time and again.

So how about this: Have 3 types of grants:

- grant on the object itself, but not the child

- grant on the children, but not the object itself

- grant on all children of a certain object_type, but not the object itself.

Before you say "permissions is slow already, this will just make it slower", we have a design at hand which is known to speed things up considerably:

Instead of having one row per (object_id, grantee_id, privilege), like you do today, have a table with a single row per (object_id, grantee_id), and with one column for each privilege in the system.

Of course, that number can fluctuate, but if we just create about 500 spare columns with generic names, that should be good enough for the time being. Plus we want to get rid of custom privs, not add to them.

Branimir has some experience with this, and can help us implement it for OpenACS, and he claims that it made permissions checks a zip.

/Lars

Requirement:
------------

- I want to grant 'admin' on all news items to user x.

Dave's Design:
--------------

Create a site-wide "News" group, etc. -- see above.

My conceptual design proposal:
------------------------------

Instead of thinking of this as granting privs on *packages* think about it as granting privs on *objects*.

What you want to do is grant 'admin' on all objects of type 'news_items'.

One possible implementations:
-----------------------------

Add a column 'object_type' to the acs_permissions table, which defaults to 'acs_object', menaning this permission is granted on all object types.

Change the permissions check procs/views to also check whether the object in question is a subtype of the value of object_type column in the acs_permissions table.

... there are other possible implementations, if you agree with me on the conceptual design.

Comments?

The reasoning for my design was to limit administration of an object type under a context. The context would most likely be a subsite. It could be a folder instead. The key is that there is a group that "owns" the folder by having a certain relationship to the folder. The application then grants all rights to that group or relational segment within that group.

The key is that we don't have an ownership concept in openacs, so I guess this is one way to do it.

I think it is a good idea to also be able to grant permission by object type, so the concepts are complementary.

Lars, in response to your last paragraph: you only need one group, probably per mounted instance (for instance privileges), or per subsite (for subsite wide privs). But each grant 'write', 'read', 'admin' would need a separate rel_type (only three for an entire OACS installation). Checking for the membership type in a certain group would be the same as checking the permission to do an action. But I think having the 'write' membership on a news package would not imply I could change someone elses posting, that would be handled by direct permissions on the news object itself. But if a certain membership is required to access a page where administrative functions are available, you don't need to look at direct or indirect permissions on objects.

At any rate, if you can create a site which somehow knows the difference between data for one subsite and the next, it is obvious you can construct a unique proxy object, or group membership, hopefully automatically, that can be used to do what Dave suggests.

One key element that slows down the permissions system is the fact that we don't have one row for each (object_id, grantee_id, privilege) that applies to each object_id, grantee_id pair.

Rather we just have rows for privileges that are set explicitly.

In other words, if we set "admin" we don't expand the table with entries for "read", "write" etc.  We join against a hierarchy table.

This is necessary, unfortunately, for the current semantics.  In the one-row-per-object model we just can't set the "write" column (or bit) for an object when we set the "admin" privilege.  Or more specifically we can't blindly delete the "write" privilege when we delete the "admin" privilege - the grantee may have "write" explicitly as well as implicitly from having been granted "admin".

When I considered my bitstring implementation (one bit per perm, as mentioned above identical in concept to Branimir's notion) I couldn't see any straightforward way to maintain the current semantics.  You end up wanting to store one row for each explicit grant on an object which sets not only the granted priv but all the child privs.  There goes part of the supposed win ...

Maybe Branimir has figured out a simple way to track this while only storing one row per object, if so, he should share.  If not, then we really don't have an alternative implementation that's a lot faster in hand, do we?  Instead we have a potentially faster implementation of a permissions system with different semantics.

On the other hand the current datamodel can also be further denormalized to expand the hierarchy properly and to maintain the current semantics.

However, with a large number of permissions and complex hierarchy the tables would grow HUGE.

So I chickened out when I last visited the problem.  Huge tables are more a space problem, though, not necessarily a significant performance problem given the log2(N) performance characteristics of queries on simple tables with proper indexes.

We need to get rid of custom privileges as much as possible.  This will speed permissions checking without any change to the underlying datamodel at all, and will also make it more reasonable to consider various other denormalizations or changes to the underlying datamodel.  "foo-read" descended from "read" which implements standard "read" semantics is a waste conceptually and in practice.

That is why I proposed my original solution. Doing a standard permission check on the intended object will work fine.

My idea was a way to use the existing permissions system. That is what seems to be confusing, it what to do with all the flexibility. I just wanted to provide a way to model a requirement using the existing system.

Right, the key is how to setup permissions for a particular application. I'd like to develop a catalog of solutions for common applications. I'll start a new thread about that when I am ready.

Frank

mailto:frank_bergmann_at_project-open_dot_com
http://www.project-open.com/

I have yet to see a specific example where this level of extra complexity is needed.  I do plan (someday, eventually) to move context_id out of acs_objects since it's only used as something to hang triggers onto (all the real work is done in a hierarchy table), but that's more for efficiency than anything else.

Among other things we don't *use* sortkeys for tree hierarchies in Oracle, and I'd like to avoid it.  In fact, if PG's hierarchical queries are efficient (I think they may appear in 7.5, implemented in SQL standard fashion) I would suggest that eventually we may switch PG to use them, though we'd want timing experiments first of course (sortkeys are one reason why object creation is slower in PG than in Oracle, a good reason to be very cautious in suggesting we switch to sortkeys in Oracle so we can maintain a forest rather than a tree).

On the other hand, the context hierarchy table doesn't use sortkeys, but rather parent/child relationships, in both PG and Oracle, so once we fully separate the permission hierarchy from the physical object tree hierarchy modelling multiple hierarchies for the context structure would be possible, even if (IMO) undesirable.

As I mentioned above, the problem Dave's brought up
could be solved by having a news-admin group with admin privs on the "news_item" object type proxy object (something we should have for this and other reasons, I think).  Aplications are free to pull other tricks such as use the package object as a proxy object for specialized permission checking if necessary.

I do see that your proposal works with the existing permissions system, whereas mine proposes to make a change to that existing system to fulfill a requirement, which has surfaced time and again."

Well ... first off Dave's original post talked about "site-wide" as meaning "an entire OpenACS installation", and the object type proxy object approach does indeed meet this need.

Your comment ... well, subsites were designed to be SUBsites, not to implement what in essence are a bunch of entirely different sites within one OpenACS installation.  I realize a fair number of people want to use the subsite mechanism to implement a set of unrelated sites, personally I question whether or not it's worth the bother.  Pushing subsites into a space where they meet that need involves a lot more than some of the permissions issues that are being discussed here.

And I'm very dubious about suggestions that we make the permissions system more complex.  If changes can be made that work with the existing datamodel that's one thing, as I can see how to continue to incrementally improve the performance without much trouble.  Since I plan on moving context_id out of the object table, multiple hierarchies can also be implemented without much pain if this were to prove useful (and it probably would to do some of the stuff we're discussing, now that I've thought about it more ... Tom may be right, as much as the additional complexity bugs me).

But changes in the design adding additional functionality that require a fundamental change in the datamodel are likely to work against scalability - and permissions scalability is still an issue in OpenACS, let's face it.

But we're going to have a REAL parent_id in acs_objects in 5.2  and context_id can be used for its real purpose: inheritence of permissions.

Now ... two quick points ...

1. If we only had PG and tree_sortkeys we wouldn't need a parent_id as the sortkey encodes the set of parents (and this leads to very quick queries when you want the set of all parents, faster than CONNECT BY as no internal joining is involved).  But that's neither here nor their given our Oracle non-sortkey implementation and, IMO, the disadvantages of sortkeys in other areas.

2. Moving out context_id will get rid of certain triggers and, IMO, make the permissions inheritance API more obvious (at least there should be no excuse for confusion with a physical parent_id if we adopt this suggestion after I TIP it, oh, later this spring).  It will allow multiple inheritance hierarchies with no extra cost in terms of query  complexity/execution times I believe ... so we can decide on whether or not permissions would benefit at that time.