Permissions inheritance is a feature of the basic ACS Objects datamodel, but in practice usage is so intertwined with package instances and the operation of the site map that I've decided to discuss the subject here.

The root object type of the OpenACS system, acs_object, contains two columns that control the inheritance of permissions from other objects. The first, a boolean named security_inherit_p, if set false disables inheritance. If set true, the column context_id identifies the object from which this object should inherit permissions. By default, security_inherit_p is set true. It is up to the programmer to set context_id to a meaningful value. Normally, context_id is set to the new object's logical parent object.

Permissions inheritance, the site map, and the acs-subsite package interact in a way that makes it quite simple to control access to objects in a particular OpenACS-based website:

• The main site (the acs-subsite instance mounted at "/") inherits its permissions from a special object known as the security context root object. By default, all visitors (the special group "The Public") have read access to this object, "Registered Users" have write access, and system-wide administrators have administration access.

• When a package is mounted by the site nodes package, by default it inherits permissions from its parent in the site map. For instance, if you mount the forums package under the main subsite ("/forums"), by default all visitors can read forums, all registered visitors can post to forums, but only site-wide administrators can create new forums, delete posts, or take other administrative action.

• The site map administrator's web pages allow one to change the default permissions behavior for any mounted package. Most frequently this is done on a community, or acs-subsite, basis. For instance you might mount a subsite named "my-private-community" under the main site, and restrict read access to members of that community. All applications mounted under the subsite will by default inherit the new permissions restrictions.

• Application packages will often use the package instance's object id as the context_id for objects it creates at the top level. By default, these objects will inherit the permissions of the application, which by default also inherits its permissions from the site node under which it is mounted.

The bottom line: in nearly all cases, changing the permissions of a subsite will lead to consistent permissions behavior on the part of applications packages it controls. The permissions system follows the "law of least astonishment".