Forum OpenACS Development: Permissions UI Issues

Or more succinctly - the permissions admin UI simply sucks :)

One thing I find somewhat annoying is that each package seems to create its own permissions (wp_read, glossary_read, blah_dy_blah_dy_read, etc).

When I go to set permissions on (say) a glossary object, I have the opportunity to grant "wp_read" and any other permission in the world to that object, which is quite weird and useless.

It also means that having "admin" privs means I generally can't admin a package even though the package's context_id is set so the package sees that I have "admin" privs.  Some packages, at least, require me to set a package-specific admin priv ("glossary_admin") before I can admin the package even though I'm the uber-user with sitewide admin privs.

Ugh.

I've been wanting to raise this whole permissions mess as an issue for some time, but have been waiting until things are fairly well along (ain't going to be fixed in our first release cycle, if we want a release before 2002, anyway!)

But it's probably not terribly useful to discuss UI issues without discussing other permissions-related issues...

The fourth bullet above discusses exactly this. Namely, ACS4 has an elaborate permissions hierarchy that, if integrated and defaulted in a "smart" manner already provides these functions. If this hierarchy were somehow "exposed" so a site admin could understand and (heaven forbid) use the power of this, the system could be leveraged to a greater degree.

<apology to the Glossary author>
Glossary in particular is "stupid" in the sense that it does not, by default, make the magic "admin" permission a parent, in the permissions hierarchy, of its own "glossary_admin" permission.
</apology to the Glossary author>

I believe that this is easy to fix, although I have not coded the fix in the right place yet. Also, some of the other modules are "mindful" of this and seem to default "smarter".

Regards..

Haha. Pretty funny.

As the original Glossary author, I'll pass the "stupid design" buck onto the ACS 4 designers...

At the time that I created the Glossary Package, I was under the impression that context_id was worth a damn. I thought that by setting the context_id of any object under a package to its package instance I would actually inherit the security hierarchy of privileges from the parent object and that there would be logical hierarchy. In fact this is exactly how the original permissions designers explained it to me. In other words, I envisioned privilege inheritance something like this:

Site Wide Admin has admin privilige on Main Site

• Main Site
• Glossary Package Instance (with default permissions set)
  • glossary objects with context_id pointing at package instance

Too bad the f&*%ers were lying to me!

This hierarchy is fundamentally broken. Instead of setting the context_id of the package instance to that of the main site (or any subsite it falls under), IIRC the context_id of a new package instance is null and the intuitive security hierarchy is gone.

Permissions are "magically" set to some defaults rather than inherited. In other words kludged. I believe that you should only have to set site wide admin priviliges at the top most of the subsite hierarchy (i.e. main site) have everything below it inherit it, unless explicity reset on a per node basis.

Believe me, I spent plenty of time mulling over the permissions problem. The fact is that a Glossary Package instance can have multiple glossary objects. Therefore you may want to have individuals that only have glossary_admin privilege on a sub-set of glossary objects, but not admin privilege on the entire package instance.

Got it?

That being said there are some fundamental unsolved problems in the Glossary Package's design because acs-subsites has never lived up to its promises. I prefer the term "naive" to "stupid".

The security context hierarchy is separate from the site map hierarchy.  This is partly out of necessity since package instances can be mounted at multiple site nodes, and therefore not have a single parent to inherit from.

As for glossary_admin vs admin, if you make glossary_admin a child of admin in the privilege hierarchy, then you can provide the exact situation you describe.

I did not write/design the permissions system.  Just trying to clarify a couple things.

I think I agree with Dennis.  The glossary "admin" should pass any
security check done by the glossary module including the
"glossary_admin" check.  I guess I'm interested in "admin" being a
standardized super user at each module level and I agree with Don
about a standardized "read" and "write" privilege as well.

Personally I'd prefer to say that if a person or group needed admin
privileges over a module but not over a child module then it should
granted on the parent and then explicitly denied on the children
since the site will, in my opinion, be much more manageable and
understandable and those cases should be rare.

The idea of the "glossary_admin" doesn't bother me too much.  Unless
the child object is another glossary the permissions would be
ignored and work exactly as Walter intended.

As far as "stupid" programmers or code, my first big project was one
that I took over from another programmer.  I was surprised at how
many "stupid" things he did until I was called upon to create a
project from scratch.  Now I'm amazed at how many "stupid" (or
non-optimal is another term I like) things I
do as I'm completing my projects.

I probably left out an end code tag. How is it now?

I found the following explanation in the doc for the news module illuminating, and unlike Press and some others the permissions granularity seems to work correctly for this module also. I would think that other application types might/would have requirements for similar permissions handling.

Permissions

With the ACS4 permissions model, the news administrator need no longer coincide with the site administrator. This need only be the case right after installation. The News application has a hierarchical set of permissions which can be assigned to any party as needed. The news root privilege is news_admin which comprises news_create, news_delete, and news_read.

By default, the news_admin permission inherits from the site-wide admin. The news_read permission is assigned to the public so that all users, including non-registered users, have access to /news/. By default, the news_create permission is assigned to registered users. However, they can only submit a news items, but not approve it. Approval requires news_admin privilege or can be set to take place automatically by setting the parameter ApprovalPolicy to 'open'. The news privileges can be changed in /permissions/ by the administrator on the /news/admin/index page. The needs of an individual site, e.g. sharing the news administration duties among several individuals, are thus covered.

This comes from /doc/news/design.html on one of my servers.

Regards..

I don't have a good example of this right now, but one of the reasons why you must foo_read the foo and can't just read the foo, is that a foo object may inherit from some other object, and that other object may not just be an abstract class, but have some meaning, and possibly UI, within the toolkit. You may not want to give the read permission to the base object... hence foo_read, which only foo UI cares about.

We're talking about two different things. In your example you show a hierarchy of packages mounted in the site map. It would indeed be useful to have packages instances inherit the permissions of their parent nodes in the hierarchy.

I was refering to to the permissions themselves; 'read', 'write' etc. which can form a hierarchy (if you have 'read' permission then you have 'foo_read' because 'foo_read' is a child of 'read'), and also acs_objects (a foo object being a child of acs_group, for example).

Whenever you create a foo object from within the foo package, you also create an acs group, accessible from within acs-subsite, acs-admin or wherever. Because the foo object and the group object share the same object_id then any permission you apply to your foo also applies to the group. There is a forced inheritence of permissions backwards up the acs object hierarchy.

Sometimes you do not want to give users random permission ('read' permission means something different to each package, it has it's own application specific context) to the 'basic' objects of your new object type.

...but don't all acs objects have the same type of parent/child relationship?

No... 😊

An acs object's type inheritence is defined by its object_id, which it shares with all the objects that are above it in the hierarchy that had to be created to collectively define the top level 'foo' object, and all the objects below it that had to be created if foo is itself a parent type of some other type.

An acs object's security inheritence is defined by its context_id, and the setting of the security_inherit_p flag.

You still end up with the problem I outlined above. When you *apply* a permission, it is permission x on object_id y for user_id z. As acs objects which are in the same inheritence line share the same object_id you are applying a direct permission on each of those objects. The context_id which defines security inheritence does not play any role in this.

First of all, I'm not suggesting removing the ability to define package-specific permissions.  In Stephen's example of a base class that wants to "keep secrets", that base class itself may want define its own permissions.  Or, perhaps restrict viewing to admins...

Or perhaps visitation to the UI pages is restricted to certain groups of users ...

Or ...

The point I'm making is that typically we'll view objects as being atomic, and won't be granting permissions to the various base types on an individual basis.

If we have a hierarchy like:

content_revision->image->wp_image_attachment

I'm unlikely to want to add "content_revision_read", "image_read", and "wp_image_attachment_read" permissions to each object just so I can allow a user to see my wp-specific type data ("where to display this") while simultaneously hiding the image the package wants to display!

One could kludge around standard permissions in Stephen's example.  That doesn't require us to forgo standard permissions in the typical case.

There may be other reasons to do so, however...

I think Walter's comments can be addressed by proper use of context_id and security_inherit_p, combined with package-specific UIs that let admins choose permissions options based on clear English descriptions of what each option will do.

<blockquote><i> a content item and an image are objects in their own right, they'll show up in any CMS interface at least.</i></blockquote>
You're right, but this is because the CMS is broken.  See my previous comment about this fact probably being a historical artifact.
<p>
(the CMS began as a "non-ACS alternative to the ACS", i.e.was developed to play alone, not with friends, and as such makes no effort to determine where content comes from.  And Karl Goldstein, it's architect, developed a separate db api, among other things, rather than make the least attempt to integrate their efforts with ongoing ACS development, regardless of merit).
<p>
You're just seeing an artifact of a very broken effort at integration, which was partial at best and at worst better not discussed in public.
It's left to us to clean up this mess.  Fortunately, the next mess (ACS 5) probably won't be completed and will be such a mess that no rational person will touch it.  So we won't feel compelled to clean it up :)
<p>The CMS should play with CMS content only.  The CR was billed as a general tool for (non-CMS) packages.  It's not a general tool, and your post simply amplifies points made elsewhere to that effect.
<p>We shouldn't let a broken CMS govern our thinking, no more than we should look at the template package's so-called parameter parsing and decide to toss ad_proc overboard...
<p>We should look forward and think about how things *should* work, rather than unravel how incompatible chunks are barely kludged together and then accept that understanding as a blueprint to follow without critically examining the result.

Roger, I'm not sure... Here's some hierarchies:

• Site Node Hierarchy

  These are the folders/direcories/section with a URL, mapped to some directory/folder somewhere, somehow in the file system. Packages are mounted on nodes and can be given a unique package_id.

• Object Inheritence Hierarchy

  ACS objects can have base objects, which can have base objects etc. They all share an object_id.

• Object Security Context Hierarchy

  ACS objects have a context_id. If security_inherit_p is marked 't' (default) then when asking the question 'can I read object_id 42?', if that object has had no permissions applied to it, we defer to it's security context, and it's security context, and so on.

• Privilege Hierarchy

  A privilege is a label we use to reperesent some action(s) we'd like to control. Like ACS objects, privileges can have parents, grandparents etc. A privilege higher in the hierarchy is equivalent to the sum of all the privileges derived from it.

These cover two prongs of the 'user x, privilege y, object z' triad ('user x' being covered by a whole bunch of other hierarchies...).

When the request processor runs it checks whether you have read permission of the node_id in question before handing off control to the code in the page belonging to the package mounted at that node. Permission inheritence via the Site Node Hierarchy is complicated by the fact that packages can be mounted multiple times with the same package_id (the co-branding feature). Typically, high level permission checking is performed against the package_id, and a package's objects have their context_id's set to the package_id. If a package is mounted in two or more places, to which node_id do you set the package's context_id?

There needs to be some juggling done here; it's not as simple as ensuring that freshly mounted 'thingies' deffer permissions to a parent 'thingy', rather than the parent subsite, but not impossible...

<blockquote><i>In fact, of the many things within CR/CMS to be fixed, this isn't one of them. CMS contains (and will contain) pages which accept object_id's and perform actions upon them
</i></blockquote>
I strenuously disagree.  The current behavior of the CMS is neither feature nor bug, but rather historical artifact (it began standalone and still takes the POV, if you will, that it and only it generates content).
<p>Users shouldn't muck with content object created by, say, the SDM in the CMS.  Random mucking around in the CMS will likely break behavior in the package actually creating the content.  Such packages will likely have assumptions about the structure of the content tree it is maintaining.
<p>The CMS and CR are too closely coupled, and that should be fixed.  It was OK when the CMS was a standalone application.  I view this close coupling as an indication that the integration of the CMS was done hastily and is incomplete.  Just as I view the fact that the CMS maintains its own login code (requiring a screen name) rather than depend on the standard ACS user login/management code as a symptom of hasty and incomplete integration.
<blockquote><i>
An object_id is a revision_id is an image_id is a wp_image_attachment_id. The same ID number appears in many tables which belong to many packages.
</i></blockquote>
Duh.  You don't think I know that?  This isn't a case of my not understanding how things work.  This is a case of my *disagreeing* with how things work.  So let's skip the tutorial snippets, OK?

<blockquote><i> What if your new object inherited from user or group or apm_package (not so strange, actually...)?</i></blockquote>
I don't see this changing anything, frankly.
<p>For starters, I'm not suggesting that we remove the capability for packages to add their own permissions or hierarchies (I'm starting to sound like a broken record but at some point hopefully you'll understand this).  I'm simply suggesting that the administration of permissons would be a lot simpler if we had a reasonable set of system-wide permissions available for use by packages.
<p>I fail to see how having 100 different flavors of "read" permission for 100 different packages can be considered a user friendly approach.
<p>One such permission might deal with personal data deemed private that should only be viewable by a subset of users.  Obviously reading personal information should require something other than a general "read" permission on the object.  This really should be true for type "user" itself regardless of issues introduced by derivation, frankly.
<p>If one requires a separate permission to view private information, then granting "read" to an object derived from "users" won't expose that information.
<p>This may not be the specific case you had in mind but I suspect I can come up with a solution to any specific example you care to come up with that doesn't require each and every package in the world to have its own custom "read", "write" and "admin" privilege.
<p>If we *do* need this fine level of granularity perhaps some method of scoping permissions to a particular package is needed.  That's what's being done - very clumsily - by the unenforced naming convention that's now being used in a very ad hoc manner. The fact that the current convention is both ad hoc and unenforced makes it both error-prone and butt-ugly.

<blockquote><i>I was just offering the opinion that the folks who wrote the packages at ArsDigita didn't just pull this off the top of their head to annoy you, maybe they had a reason </i></blockquote>
But maybe the core design team's reasoning was faulty...
<p>Keep in mind that one of the core designers claimed that he didn't understand why people felt that the permissions admin UI was insufficient in the first place!  Back in 4.0 which in general had admin UI that was even lamer than we see in 4.2!  That shows a rather remarkable lack of insight IMO.
<p>As far as scoping permissions, this idea's actually been floating around in my head for a few weeks now.  I'm not yet convinced it is necessary but it would be a far cleaner solution than we see now, and would help with the admin UI clean-up.  It may also not be efficiently implementable in both RDBMS's we want to support.
<p>I'm curious about one thing, though ... if the current permissions  granularity-by-naming is really useful, isn't the package level a rather stupid place to do it?
Shouldn't OBJECT TYPES each define a suite of permissions unique to the type so you can truly do what you want - control visibility of each base type's data in an inheritance hierarchy?
<p>BTW the fact that package instances can be mounted in multiple places makes context_id for packages virtually useless, not simply "complicated", ISTM!  This has been another annoyance percolating in my mind.

After having taken a serious look at the permission system and how we might use it in dotLRN, I think I might have a couple of thoughts to contribute.

1. The UI for permissions is fairly inexistent. That's a problem. No doubt about that. But that's not a design problem, that's just a missing chunk of code. We need to write it. That's all there is to say about that :)

2. I actually think the current design is quite good. I see very little that isn't doable in the current system (one caveat is my point number 3). I think there is certainly an issue of formalizing HOW one is SUPPOSED to use the permission system. It makes a lot of sense to have hierarchical permissions and to ALWAYS root them at admin, read, write, or create (the top-level ones). A properly working context_id mechanism with security_inherit_p used correctly is in fact pretty good: it's the leaf-level code that should decide whether to allow inherited permissions from above, thus setting the proper context_id for a good security inheritance architecture, and the appropriate security_inherit_p depending on whether you want to inherit or not in a particular case.

3. in dotLRN, we have hit an interesting situation. By default, the site node system is supposed to mount new packages and set the context_id to be either the parent node, or if an object is attached to the parent node, that very object (which is, AFAICT, always a package instance). Now, dotLRN uses a lot of existing packages, like bboard, which automatically set their data's default context_id to be their local package_id: a new forum gets created with context_id set to the bboard's package ID. That is a perfectly correct default behavior, and dotLRN simply needs to deal with that. So, a course in dotLRN is a subsite with packages instantiated and mounted underneath it. Thus, we want the package instances mounted at a particular course mount point to inherit permissions from the course itself. But does it make sense for a dotLRN course to be an extension of package_id so that it can be directly mounted at a site node? I'm not so certain... Then does it make sense to instantiate a package that inherits from something totally different, like maybe a dotLRN course (which is a type extension of acs_group)? I think this can be resolved, but I'm throwing it out there to see what people think.

In general, I think improvements definitely need to be made w/ respect to UI and optimization, but I'm not seeing any clear problems with the design. Maybe I'm missing something?