Forum OpenACS Q&A: Permissions system questions

Posted by Jason B. Standing on 10/30/07 04:22 PM

Hello there,

I'm trying to get to the bottom of how the permissions system and its hierarchical nature works, as we're having some hassles with the acs_permissions table in our application. The table currently has somewhere in the order of 167449884 records in it, which is making indexing a bit of a headache.

I've tried to read the various bits of documentation I can find to try to make sense of it all, however obviously as an organic project with things constantly changing, no sooner have I read something and thought I've got the hang of it than I read something else to suggest that it's all different...

Essentially the problem as I see it boils down to the fact that for every single GENERAL_COMMENTS object we're getting between 300 and 1100 ACS_PERMISSIONS rows written, each granting Read permission to a system user.

As I understand it, there's meant to be a hierarchy described in acs_object_context_index which enables a user/group relationship and therefore reduce the number of permission rows that need to be written. We've got a GROUP-(GROUP-(USER structure, so I would have expected to see records with n_generations=2 with object_id's of the various user_id's and an ancestor_id of the overall group_id.

However, looking at what's in our acs_object_context_index table it seems that all of the child objects related to the parent group are in fact acs_rels entries... so my guess is that whatever code is dishing out read permissions on gc_comments (or possibly the cr_revisions concerned) isn't able to traverse the hierarchy to find a parent, and is instead assigning everything at the lowest leaf.

Being fairly new at the permissions system, I'm a little uncertain where to start looking, but does this look right to everyone, and/or where should I be following up to try to streamline this?

2: Re: Permissions system questions (response to 1)

Posted by Jason B. Standing on 10/30/07 04:27 PM

I forgot to mention, the chief reason we're paying any attention to this is that the ACS_PERMISSIONS table is presently taking up about 4gb of disk space, and the index on that table is taking up just over 5gb.

3: Re: Permissions system questions (response to 1)

Posted by Claudio Pasolini on 10/31/07 08:33 AM

This document explains why the acs_object_context_index is so big.

Group's hierarchy is great to simplify permission management, but the actual permissions are maintened at detail level.

4: Re: Permissions system questions (response to 1)

Posted by Jason B. Standing on 11/01/07 01:44 PM

Thanks for that Claudio.

I agree, but that's not the table I was referring to. As I said, our ACS_PERMISSIONS table is the one that's enormous, and as far as I can tell the reason for that is because our system isn't taking advantage of the hierarchy, and I'm trying to work out why that is.

In fact, the situation we're getting is specifically referenced in that document:

The naive approach to managing system security would be to require application developers to store permission information explicitly about every object, i.e. if the system has 100,000 and 1,000 users who have the read privilege on all objects, then we would need to store 100,000,000 entries of the form:
object_id grantee_id privilege
object_id_1 user_id_1 'read'
object_id_1 user_id_2 'read'
...

Although quite feasible, this approach fails to take advantage of the fact that objects in the system are commonly organized hierarchally, and permissions usually follow the hierarchical structure, so that if user X has the read privilege on object A, she typically also has the read privilege on all objects attached under A.
The general permission system, as implemented in OpenACS 4.x, takes advantage of the hierarchical organization of objects to unburden developers of the necessity to explicitly maintain security information for every single object. There are three kinds of hierarchies involved. These are discussed in the following sections.

It seems that for some reason our hierarchy is being built using acs_rels objects rather than parties, and the hierarchy traversing code isn't able to follow via acs_rels, if indeed it's trying to. As I said, I'm pretty new at this and don't know where to look to diagnose what's actually going on.

You said

Group's hierarchy is great to simplify permission management, but the actual permissions are maintened at detail level.

however the document would appear to suggest the opposite.

Incidentally, I pored over the "tediously explained" document in some detail, and was a little confused by the following:

The code has been modified since this document was written so it is now out of date.

Why is this document included in current documentation if it had been marked as Out Of Date in 2003? It's a great & helpful document, disadvantaged only by the big disclaimer at the top saying "the product hasn't actually worked like this for some time now"...

5: Re: Permissions system questions (response to 1)

Posted by Gustaf Neumann on 11/02/07 01:57 PM

Jason, you wrote:

Essentially the problem as I see it boils down to the fact that for every single GENERAL_COMMENTS object we're getting between 300 and 1100 ACS_PERMISSIONS rows written, each granting Read permission to a system user.

i am no expert on general-comments, but i still wonder, what is going on. I don't see the behavior you are describing on my test installation. From your description, it sounds like the

	    permission::grant -object_id $comment_id \
		              -party_id $user_id \
		              -privilege "read"

in general_comment_new adds for every member of party a tuple to acs_permissions. In current versions of OpenACS, i see no code doing this, neither in PostgreSQL nor in Oracle. What version of OpenACS are you using? On PostgreSQL or Oracle? Are you sure that you have no custom version of general-comments, that differs form the released code?

6: Re: Permissions system questions (response to 1)

Posted by Ciaran De Buitlear on 11/28/07 05:27 PM

I believe this is code that we added to Openacs before it was shipped to you. Just getting to the bottom of this now.