Forum OpenACS Development: Response to Permissions UI Issues

Collapse
Posted by Stephen . on
Roger, I'm not sure... Here's some hierarchies:
  • Site Node Hierarchy

    These are the folders/direcories/section with a URL, mapped to some directory/folder somewhere, somehow in the file system. Packages are mounted on nodes and can be given a unique package_id.

  • Object Inheritence Hierarchy

    ACS objects can have base objects, which can have base objects etc. They all share an object_id.

  • Object Security Context Hierarchy

    ACS objects have a context_id. If security_inherit_p is marked 't' (default) then when asking the question 'can I read object_id 42?', if that object has had no permissions applied to it, we defer to it's security context, and it's security context, and so on.

  • Privilege Hierarchy

    A privilege is a label we use to reperesent some action(s) we'd like to control. Like ACS objects, privileges can have parents, grandparents etc. A privilege higher in the hierarchy is equivalent to the sum of all the privileges derived from it.

These cover two prongs of the 'user x, privilege y, object z' triad ('user x' being covered by a whole bunch of other hierarchies...).

When the request processor runs it checks whether you have read permission of the node_id in question before handing off control to the code in the page belonging to the package mounted at that node. Permission inheritence via the Site Node Hierarchy is complicated by the fact that packages can be mounted multiple times with the same package_id (the co-branding feature). Typically, high level permission checking is performed against the package_id, and a package's objects have their context_id's set to the package_id. If a package is mounted in two or more places, to which node_id do you set the package's context_id?

There needs to be some juggling done here; it's not as simple as ensuring that freshly mounted 'thingies' deffer permissions to a parent 'thingy', rather than the parent subsite, but not impossible...