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.

Permissions Overview

Who (grantee_id) can do what @@ -90,7 +90,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: -

object_id	grantee_id	privilege
object_id_1	user_id_1	'read'
object_id_1	user_id_2	'read'
...
object_id_1	user_id_n	'read'
object_id_2	user_id_1	'read'
object_id_2	user_id_2	'read'
...
object_id_2	user_id_n	'read'
...
...
object_id_m	user_id_1	'read'
object_id_m	user_id_2	'read'
...
object_id_m	user_id_n	'read'

object_id	grantee_id	privilege
object_id_1	user_id_1	'read'
object_id_1	user_id_2	'read'
...
object_id_1	user_id_n	'read'
object_id_2	user_id_1	'read'
object_id_2	user_id_2	'read'
...
object_id_2	user_id_n	'read'
...
...
object_id_m	user_id_1	'read'
object_id_m	user_id_2	'read'
...
object_id_m	user_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 @@ -105,7 +105,7 @@

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 @@ -139,23 +139,23 @@ 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, 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. -
object grantee privilege
A Joe read
+
object grantee privilege
A Joe read
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: -
object ancestor n_generations
A A 0
B B 0
B A 1
C C 0
C A 1
D D 0
D B 1
D A 2
E E 0
E B 1
E A 2
F F 0
F C 1
F A 2
+
object ancestor n_generations
A A 0
B B 0
B A 1
C C 0
C A 1
D D 0
D B 1
D A 2
E E 0
E B 1
E A 2
F F 0
F C 1
F A 2
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 @@ -226,7 +226,7 @@ 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
@@ -276,7 +276,7 @@ privileges on an object, it is sufficient to grant the user the admin privilege to which the first four privileges are tied. Privileges are structured as follows. -
admin
create delete read write
+
admin
create delete read write
Note that admin privileges are greater than read, write, create and delete privileges combined. Issuing someone read, write, create and delete privileges will @@ -326,7 +326,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. -
+
parties
persons @@ -418,7 +418,7 @@
The acs_rels table entries would look like so: -
+
rel_type object_one @@ -463,7 +463,7 @@
The relevant entries in the acs_rels look like so. -
+
rel_type object_one @@ -681,7 +681,7 @@
Note that in the above example, acs_permissions had only one entry that needed to be deleted: -
+
object_id grantee_id