OpenACS Permissions Tediously Explained

+OpenACS Permissions Tediously Explained

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 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 may end up writing seemingly correct code that crashes their system in @@ -97,26 +97,44 @@ 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

+ A + `object_id=10` -
B + +
+ B + `object_id=20` -		C + +	+ C + `object_id=30` -
D + +
+ D + `object_id=40` -	E + +	+ E + `object_id=50` -	F + +	+ F + `object_id=60` -

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

Table�11.3.�acs_objects example data

object_id	context_id
20	10
30	10
40	20
50	20
60	30

Table�11.3.�acs_objects example data

object_id	context_id
20	10
30	10
40	20
50	20
60	30

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, @@ -203,31 +221,43 @@ 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. -

+ A `object_id=10` readable�by�Joe - ��
+ �� +
+ B `object_id=20` readable�by�Joe -��		+�� +	+ C `object_id=30` security_inherit_p�=�'f' not�readable�by�Joe - ��
+ �� +
+ D `object_id=40` - ��	+ �� +	+ E `object_id=50` - ��	+ �� +	+ F `object_id=60` security_inherit_p�=�'f' not�readable�by�Joe - ��

Privilege Hierarchy

+ ��

Privilege Hierarchy

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: @@ -283,10 +313,18 @@ reasonably small, there is no pressing need to cache the flattened ansector-descendant view of the privilege hierarchy in a specially maintained table like it is done in the case of the context hierarchy. -

Party Hierarchy

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

parties
persons	groups
users

+    

+	      parties
+	    

+	      persons
+	    
+	      groups
+	    

+              users
+	    
   create table parties (
       party_id
           not null
@@ -370,7 +408,13 @@
     

       The acs_rels
       table entries would look like so: 
-    
rel_type object_one object_two

+    

+              rel_type
+	    
+              object_one
+	    
+	      object_two
+	    

 	      membership_rel
 	    
 	      Pranksters
@@ -405,7 +449,13 @@
     
       The relevant entries in the 
       acs_rels look like so. 
-    
rel_type object_one object_two

+    

+              rel_type
+	    
+              object_one
+	    
+	      object_two
+	    

 	      composition_rel
 	    
 	      Pranksters
@@ -534,7 +584,7 @@
       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.
-    
Putting It All Together

+    
Putting It All Together

       Security information is queried by calling the acs_permission.permission_p
       function in OpenACS 4.x. 
     
  
@@ -616,7 +666,13 @@
     

       Note that in the above example, acs_permissions had only
       one entry that needed to be deleted: 
-    
object_id grantee_id privilege

+    

+              object_id
+	    
+	      grantee_id
+	    
+	      privilege
+	    

 	      default_context
 	    
 	      registered_users
@@ -626,7 +682,7 @@
       The above script would never get around to deleting this entry because it had
       to loop through a gazillion rows in the humongous
       acs_object_party_privilege_map view. 
-    
Appendix: Various View Definitions
+    
Appendix: Various View Definitions
 create or replace view acs_object_party_privilege_map
 as
 select