Forum OpenACS Development: Re: Permissions on categories

Posted by Gustaf Neumann on
xowiki does already something what you describe. xowiki's page types are subtypes of cr_revision. via policies, it is possible to base the access rights (a) on arbitrary attributes of the object and (b) to differentiate the access rights on the class of the object (also an acs_type). xowiki does not have a file-store like interface and has no folders (yet). however, the access right policies seem well suited for this task and can be easily set differently per instance. See also
Posted by Malte Sussdorff on
I have thought about making xofs or something like that copying the code from xowiki, but what stopped me was the fact that I would need to create a subtype of xofs::file on the fly as the adding of file or project "types" needs to be something the end user should be able to configure. Which would mean to create the subtype on the fly (no problem) and keep it persistent, and here I am not sure if I can just create the subtype in the DB and it will work or do I need to write this into the filesystem as well as I need to do with classes?

On a related note: Excellent that you work on the xowiki-faq. This will help a lot of users!

Posted by Gustaf Neumann on
malte, there is no need to copy code from xowiki, one can use xowiki and reuse it like e.g. in the s5 package. There is also no need to create a high number of subtypes. Here are two approaches, the second one requires no new subtype at all.

1) One can subclass xowiki::File to e.g. XFile, add an "security label" as in mandatory access control systems as an additional attribute (security_label). If this label is an acs-object, one can define a policy rule like

Class XFile -array set require_permission {
download {{security_label read}}
one can define as security labels acs-objects "public", "internal use", "confidential", "top secret" and give the users rights to these (acs) objects (e.g. via groups). When an XFile is created, the security labels are associated with the files. With the policy definition above, you should be done.

2) maybe less efficient, but less programming work, using categories as security labels.

xotcl-core defines a couple of "privileges" such as "swa", "login", "creator" which are not necessarily based on acs_permissions. These privileges are defined as single words in the policy rules. One can define custom privileges as well, which are methods with names like "privilege=SOMETHING".

You can define a category tree named "security labels", map the tree to the instance, require the user to provide categories like "public" .. "top secret" for the files.
You can define such a privilege method (e.g. privilege=label), and check in this method, whether the object has such a label. Finally check, if the user has clearance for this label. Since categories are already acs-objcets, rights could be provided for the category objects.

There is an example for a custom privilege rule in generic-procs (privilege=creator, which we used for the conference registration).

Posted by Ryan Gallimore on
Hi Gustaf,

Thanks for the instructions. Is it possible to take an existing category tree, like:

Release Notes

and grant read/write/admin on any xowiki pages inside each?

For instance I may have a user, Joe, and I want him to be able read-only the pages in Release Notes, edit the Documentation pages, but not even see the Support category.