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.16 -r1.17 --- openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html 11 Nov 2003 12:54:57 -0000 1.16 +++ openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html 19 Nov 2003 15:44:51 -0000 1.17 @@ -1,6 +1,6 @@ -OpenACS 4.x Permissions Tediously Explained
Prev Chapter�8.�Development Reference Next

OpenACS 4.x Permissions Tediously Explained

+OpenACS 4.x Permissions Tediously Explained

Alex logo
Prev Chapter�8.�Development Reference Next

OpenACS 4.x Permissions Tediously Explained

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

Overview

+

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

Overview

The general permissions system has a relatively complex data model in OpenACS 4.x. Developers who haven't had the time to learn the internals of the data model may end up writing seemingly correct code that crashes their system in @@ -85,7 +85,7 @@ 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: -

Table�8.1.�

object_idgrantee_idprivilege
object_id_1user_id_1'read'
object_id_1user_id_2'read'
...
object_id_1user_id_n'read'
object_id_2user_id_1'read'
object_id_2user_id_2'read'
...
object_id_2user_id_n'read'
...
...
object_id_muser_id_1'read'
object_id_muser_id_2'read'
...
object_id_muser_id_n'read'

+

object_idgrantee_idprivilege
object_id_1user_id_1'read'
object_id_1user_id_2'read'
...
object_id_1user_id_n'read'
object_id_2user_id_1'read'
object_id_2user_id_2'read'
...
object_id_2user_id_n'read'
...
...
object_id_muser_id_1'read'
object_id_muser_id_2'read'
...
object_id_muser_id_n'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 @@ -100,7 +100,7 @@

Context Hierarchy

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

Table�8.2.�

A

+

Table�8.1.�Context Hierarchy Example

A

object_id=10

B

object_id=20 @@ -113,26 +113,26 @@

F

object_id=60

- This can be represented in the - acs_objects table + This can be represented in the + acs_objects table by the following entries: -

Table�8.3.�

object_idcontext_id
2010
3010
4020
5020
6030

+

Table�8.2.�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, we can compute that object 40 is the second-generation descendant of object 10. With this in mind, if we want to record the fact that user Joe has the read privilege on objects A, ..., F, we only need to record one entry in the - acs_permissions table. -

Table�8.4.�

objectgranteeprivilege
AJoeread

+ acs_permissions table. +

objectgranteeprivilege
AJoeread

The fact that Joe can also read B, C, ..., and F can be derived by ascertaining that these objects are children of A by traversing the context hierarchy. As it turns out, hierarchical queries are expensive. As Rafael Schloming put it so aptly, Oracle can't deal with hierarchies for shit.

One way to solve this problem is to cache a flattened view of the context tree like so: -

Table�8.5.�

objectancestorn_generations
AA0
BB0
BA1
CC0
CA1
DD0
DB1
DA2
EE0
EB1
EA2
FF0
FC1
FA2

+

objectancestorn_generations
AA0
BB0
BA1
CC0
CA1
DD0
DB1
DA2
EE0
EB1
EA2
FF0
FC1
FA2

Note that the number of entries in the flattened view grows exponentially with respect to the depth of the context tree. For instance, if you have a fully populated binary tree with a depth of n, then the number of entries @@ -147,10 +147,10 @@ create table acs_object_context_index ( object_id not null - constraint acs_obj_context_idx_obj_id_fk references acs_objects(object_id), + constraint acs_obj_context_idx_obj_id_fk references acs_objects (object_id), ancestor_id not null - constraint acs_obj_context_idx_anc_id_fk references acs_objects(object_id), + constraint acs_obj_context_idx_anc_id_fk references acs_objects (object_id), n_generations integer not null constraint acs_obj_context_idx_n_gen_ck check (n_generations >= 0), @@ -168,7 +168,7 @@ with respect to the depth of the context tree.

The acs_object_context_index is kept in sync with the - acs_objects + acs_objects table by triggers like this: 

 create or replace trigger acs_objects_context_id_in_tr
@@ -198,12 +198,12 @@
     end if;
 end;

- One final note about - acs_objects. By setting + One final note about + acs_objects. By setting an object's security_inherit_p column to 'f', you can stop permissions from cascading down the context tree. In the following example, Joe does not have the read permissions on C and F. -

Table�8.6.�


+


A
object_id=10
readable�by�Joe
@@ -231,7 +231,7 @@ Privileges are also organized hierarchically. In addition to the five main system privileges defined in the ACS Kernel data model, application developers may define their own. For instance, the Bboard package defines the following privileges: -

Table�8.7.�

privilege
create_category
create_forum
create_message
delete_category
delete_forum
delete_message
moderate_forum
read_category
read_forum
read_message
write_category
write_forum
write_message

+

privilege
create_category
create_forum
create_message
delete_category
delete_forum
delete_message
moderate_forum
read_category
read_forum
read_message
write_category
write_forum
write_message

By defining parent-child relationship between privileges, the OpenACS data model makes it easier for developers to manage permissions. Instead of granting a user explicit read, write, delete, @@ -240,7 +240,7 @@ privilege to which the first four privileges are tied. To give a more detailed example, the Bboard privileges are structured as follows. -

Table�8.8.�

admin
createdeletereadwritemoderate forum
create categorycreate forumcreate messagedelete categorydelete forumdelete messageread categoryread forumread messagewrite categorywrite forumwrite message

+

admin
createdeletereadwritemoderate forum
create categorycreate forumcreate messagedelete categorydelete forumdelete messageread categoryread forumread messagewrite categorywrite forumwrite message

The parent-child relationship between privileges is represented in the acs_privilege_hierarchy table: 

@@ -286,7 +286,7 @@

Party Hierarchy

Now for the third hierarchy playing a promiment role in the permission system. The party data model is set up as follows. -

Table�8.9.�

parties
personsgroups
users
+    
parties
personsgroups
users
   create table parties (
       party_id
           not null
@@ -368,9 +368,9 @@
            check (member_state in ('approved', 'banned', 'rejected', 'deleted'))
   );
     

-      The acs_rels 
+      The acs_rels
       table entries would look like so: 
-    
Table�8.10.�
rel_typeobject_oneobject_two

+    
rel_typeobject_oneobject_two

 	      membership_rel
 	    
 	      Pranksters
@@ -394,7 +394,7 @@
       of Pranksters.  We say that the Pranksters group
       is composed of 
       groups Merry Pranksters and Sad Pranksters.  This
-      information is stored in the acs_rels
+      information is stored in the acs_rels
       and composition_rels tables. 
     
 create table composition_rels (
@@ -404,8 +404,8 @@
 );
     

       The relevant entries in the 
-      acs_rels look like so. 
-    
Table�8.11.�
rel_typeobject_oneobject_two

+      acs_rels look like so. 
+    
rel_typeobject_oneobject_two

 	      composition_rel
 	    
 	      Pranksters
@@ -472,16 +472,16 @@
   ) organization index;
     

       The group_component_index table stores a flattened representation of the
-      group composition hierarchy that is maintained in sync with the acs_rels
+      group composition hierarchy that is maintained in sync with the acs_rels
       and composition_rels tables through triggers. 
     

       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
-      group_member_index can be trivially derived by joining
-      membership_rels,
-      acs_rels,
-      and group_component_index. Here
+      group_member_index can be trivially derived by joining
+      membership_rels,
+      acs_rels,
+      and group_component_index. Here
       is a view that does it. (This view is not part of the OpenACS Kernel data model.)
     
 create or replace view group_member_view
@@ -507,7 +507,7 @@
   and r.object_id_one = gci.component_id;
     

       A heuristic way to verify that group_member_view is essentially identical
-      to group_member_index is to compute the
+      to group_member_index is to compute the
       symmetric difference between the two: 
     
 select
@@ -530,7 +530,7 @@
     

       The query returns no rows.  The important point is, if we
       have a flattened view of the composition hierarchy -- like one provided
-      by the group_component_index table --
+      by the group_component_index table --
       membership relationship resolution can be computed trivially with no hierarchical
       queries involved. There is no need to keep the view in a denormalized
       table, unless doing so results in substantial performance gains.
@@ -562,7 +562,7 @@
   end acs_permission;
     

       The function simply queries 
-      acs_object_party_privilege_map,
+      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,
@@ -616,7 +616,7 @@
     

       Note that in the above example, acs_permissions had only
       one entry that needed to be deleted: 
-    
Table�8.12.�
object_idgrantee_idprivilege

+    
object_idgrantee_idprivilege

 	      default_context
 	    
 	      registered_users