OpenACS 4.x Permissions Tediously Explained

+OpenACS 4.x Permissions Tediously Explained

Prev	Chapter�8.�Development Reference	Next

OpenACS 4.x 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 obsolete. See this forum thread.

Overview

The general permissions system has a relatively complex data model in OpenACS 4.x. @@ -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_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 @@ -100,7 +100,7 @@

Context Hierarchy

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

Table�8.2.�

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_id	context_id
20	10
30	10
40	20
50	20
60	30

Table�8.2.�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. -

Table�8.4.�

object	grantee	privilege
A	Joe	read

+ acs_permissions table. +

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: -

Table�8.5.�

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 @@ -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

create

delete

read

write

moderate forum

create category

create forum

create message

delete category

delete forum

delete message

read category

read forum

read message

write category

write forum

write message