Forum OpenACS Development: Bugs in permission checking?

Collapse
1: Bugs in permission checking?
Posted by Luke Pond on 06/20/01 02:13 AM
I encountered two problems today when trying to work with the permission checking code in OpenACS4. Do any of the acs-kernel porters have time to verify or fix these?

Permissions are not inherited from object_id -3, the "Default Context"

Go to /permissions and grant a permission on the "Default Context" object. Now search down the page for the "Main Site" object, and note that the permissions you granted to "Default Context" don't show up under "Inherited Permissions". In Classic ACS they do. The bboard package makes use of this feature to specify defaults for the bboard-specific permissions.
ad_permission_p doesn't recognize direct-granted permissions
Grant a permission to yourself on a package and then call acs_permission__permission_p to see if it returns "t". As far as I can tell it doesn't. Here's an example from psql: 
openacs-4=# select * from acs_permissions where object_id=2920;
 object_id | grantee_id |       privilege       
-----------+------------+-----------------------
      2920 |         -2 | bboard_create_message
      2920 |         -1 | bboard_read_category
      2920 |         -1 | bboard_read_forum
      2920 |         -1 | bboard_read_message
      2920 |       2082 | bboard_create_forum
(5 rows)

openacs-4=# select acs_permission__permission_p
('2920', '2082', 'bboard_create_forum') = 't' as permission_p;
 permission_p 
--------------
 f
(1 row)
Collapse
2: Response to Bugs in permission checking? (response to 1)
Posted by Jon Griffin on 06/20/01 02:19 AM
I have no doubt that ad_permission_p is screwed up.

In ACSclassic this was a huge piece of $%^& and I (and a co-worker) created a work around.

See the thread on ACS won't scale, and you will see.

Permissions in general, while noble in their design, are way screwed up and probably need to be re-written.

Collapse
3: Response to Bugs in permission checking? (response to 1)
Posted by Jon Griffin on 06/20/01 02:27 AM
I actually tried the ad_permission_p on a patched ACS-Classic and it seems to work fine. It seems to be a PG problem.
Collapse
4: Response to Bugs in permission checking? (response to 1)
Posted by Luke Pond on 06/20/01 02:32 AM
Right, I should have specified I'm using the latest pre-beta code for OpenACS4 with Postgres 7.1.  The acs_permission__permission_p function was rewritten on May 1 by Matthew Avalos and perhaps not fully tested.
Collapse
5: Response to Bugs in permission checking? (response to 1)
Posted by Jon Griffin on 06/20/01 02:41 AM
That is the patch we made, but it was for acs-classic and we are using it in production. I don't think there are any problems but I don't want to guarantee it.

I suspect something didn't get ported to PG correctly. I just checked again and direct permissions are definitly working on Oracle/Classic.

Collapse
6: Response to Bugs in permission checking? (response to 1)
Posted by Dan Wickstrom on 06/20/01 03:35 AM
Luke - could you try bypassing the permission_p procedure and do the query directly from psql? 

select count(*) 
          from acs_object_grantee_priv_map
         where object_id = 2920
           and grantee_id = 2082
           and privilege = 'bboard_create_forum';

It's possible that there is a problem with the acs_object_grantee_priv_map view.

Collapse
7: Response to Bugs in permission checking? (response to 1)
Posted by Dan Wickstrom on 06/20/01 03:34 PM
I tried inheriting permissions from the default context, and that seemed to work fine for me.  I was able to grant the default_context cm_admin privileges, and this showed up in the main site as an inherited permission.

Maybe the problem is specific to the bboard permissions data-model.

Collapse
8: No bugs after all (response to 1)
Posted by Luke Pond on 06/20/01 06:09 PM
Sorry for the alarm, this turned out to be a case of user error. It was that darn triggered data change violation again. Specifically, I was calling acs_permission__add_child multiple times in a single plpgsql function, and somehow didn't notice the error that resulted (ERROR: triggered data change violation on relation "acs_privilege_hierarchy_index"). So there were no entries in acs_privilege_hierarchy for the bboard permissions.

After removing the transactional context around my calls to acs_permission__add_child, the data model was set up correctly and both the problems I mentioned above went away.

Collapse
9: Response to Bugs in permission checking? (response to 1)
Posted by Dan Wickstrom on 06/20/01 06:40 PM
Anybody who is porting a package that adds permissions should check and make sure that they don't have the same problem that Luke has uncovered.  I've come across this same problem in the core and in cms.  I've been working around it by dropping the trigger on acs_privilege_hierachy at the start of the transaction and re-enabling it before the last add_child call within the transaction.  This works because the trigger on acs_privilege_hierarchy only modifies the acs_privilege_hierarchy_index one time when the last add_child call is made with the trigger reapplied.