Index: openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html,v diff -u -r1.38 -r1.39 --- openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html 17 Jul 2006 05:38:31 -0000 1.38 +++ openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html 5 Aug 2006 05:18:20 -0000 1.39 @@ -1,19 +1,23 @@ OpenACS Permissions Tediously Explained
Alex logo
Prev Chapter�11.�Development Reference Next

OpenACS Permissions Tediously Explained

by Vadim Nasardinov. Modified and converted to Docbook XML by Roberto Mello -

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

Overview

- The general permissions system has a relatively complex data model in OpenACS. - Developers who haven't had the time to learn the internals of the data model +

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

Permissions Overview

Who + (grantee_id) can do what + (privilege) on which object + (object_id). +

+ The general permissions system has a flexible (and relatively complex) data model in OpenACS. + Developers who have not had the time to learn the internals of the data model may end up writing seemingly correct code that crashes their system in weird ways. This writeup is the result of my running into such a piece of code and trying to understand exactly what went wrong. It is geared towards developers who understand the general permissions system to the extent that is described in the - OpenACS Permissions documentation, - but who haven't had the opportunity to take a long, careful look at the + Groups, Context, Permissions documentation, + but who have not had the opportunity to take a long, careful look at the system internals.

- In OpenACS 4.x, most of the interesting tables are expected to extend (subtype) + In OpenACS, most of the interesting tables are expected to extend (subtype) the acs_objects table, i.e. they are expected to have an integer primary key column that references the object_id column of acs_objects. @@ -41,8 +45,8 @@ unique (context_id, object_id) disable );

- This means that any interesting entity (object) - in the system has an entry in the acs_objects. This + This means that items that want to use the features of the + OpenACS object system needs to have an entry in the acs_objects. This allows developers to define relationships between any two entities A and B by defining a relationship between their corresponding entries in the acs_objects table. One of the applications of this @@ -81,7 +85,7 @@ Who (grantee_id) can do what (privilege) on which object (object_id).

- The naive approach to managing system security would be to require application developers + The micromanaging approach to 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: @@ -92,15 +96,15 @@ 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 + The general permission system 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.

Context Hierarchy

Suppose objects A, B, ..., and F form the following hierarchy. -

Table�11.2.�Context Hierarchy Example

+

Table�11.2.�Context Hierarchy Example

A

object_id=10 @@ -134,7 +138,7 @@ This can be represented in the acs_objects table by the following entries: -

Table�11.3.�acs_objects example data

object_idcontext_id
2010
3010
4020
5020
6030

+

Table�11.3.�acs_objects example data

object_idcontext_id
2010
3010
4020
5020
6030

The first entry tells us that object 20 is the descendant of object 10, and the third entry shows that object 40 is the descendant of object 20. By running a CONNECT BY query, @@ -158,7 +162,7 @@

1 + 2*2 + 3*4 + 4*8 + 5*16 + ... + (n+1)*2n = n*2n+1 + 1

Despite its potentially great storage costs, maintaining a - flattened representation of the context tree is exactly what OpenACS 4.x + flattened representation of the context tree is exactly what OpenACS does. The flattened context tree is stored in the acs_object_context_index table. 

@@ -272,7 +276,11 @@
       admin privilege to which the first four
       privileges are tied. Privileges are structured as follows.
     
admin
createdeletereadwrite

-      The parent-child relationship between privileges is represented in
+      Note that admin privileges are
+      greater than read, write, create and delete privileges combined.
+       Issuing someone read, write, create and delete privileges will
+      not result in the person getting
+      admin privileges.
The parent-child relationship between privileges is represented in
       the acs_privilege_hierarchy table: 
     
   create table acs_privilege_hierarchy (
@@ -433,7 +441,11 @@
 	      Pranksters
Penelope -

+

Read acs_rels: right-side is a + subset of left-side, ie + object2 is a part of + object1. +

Another way of building up groups is by adding subgroups. Suppose we define Merry Pranksters and Sad Pranksters as subgroups of Pranksters. We say that the Pranksters group @@ -484,7 +496,7 @@ hierarchical queries, which are expensive in Oracle. As we saw in the Context Hierarchy section, one way of reducing the performance hit incurred by hierarchical queries is to cache query results in - a table maintained by triggers. The OpenACS 4.x data model defines two such tables: + a table maintained by triggers. The OpenACS data model defines two such tables: 

  create table group_component_index (
           group_id        not null
@@ -525,7 +537,7 @@
       The group_component_index table stores a flattened representation of the
       group composition hierarchy that is maintained in sync with the acs_rels
       and composition_rels tables through triggers. 
-    

+    
additional comments

       As far as the group_member_index table goes, I am not sure I understand its
       purpose.  It maintains group-member relationships that are resolved with respect
       to group composition.  Note that information stored in
@@ -587,7 +599,7 @@
       table, unless doing so results in substantial performance gains.

Putting It All Together

Security information is queried by calling the acs_permission.permission_p - function in OpenACS 4.x+. This is accessible from Tcl via the + function in OpenACS. This is accessible from Tcl via the permission::permission_p procedure. 

  
   create or replace package body acs_permission
@@ -612,17 +624,17 @@
     end;
 
   end acs_permission;
-

- The function simply queries +

problem avoidance

+ The function queries acs_object_party_privilege_map, which is a humongous view that joins three flattened hierarchies: the context tree, the privilege hierarchy, - the party composition (and membership) hierarchy. As such, - it contains an extremely large number of rows. About + the party composition (and membership) hierarchy. + It contains an extremely large number of rows. About the only kind of query you can run against it is the one performed by the acs_permission.permission_p function. Anything other than that would take forever to - finish or would ultimately result in an Oracle error. + finish or would ultimately result in a query error.

For example, do not try to do things like