Security Manager

$Id$

Introduction

The security manager serves as a locus for code that decides whether permission should be granted for the execution of certain actions in certain contexts. (The canonical example is whether a script located in document A should be allowed to manipulate or access document B.)

At this time (Feb 2006) only a small number of security actions are in this module, but the intention is that more should be located here.

The module also documents the security models that are implemented.

Pending models

List of pending security models

Specific models

Document model, overview
Plugin model (partial)
Widget model
Charset inheritance model

To-do list

To-do list

Design principles

Separability of security models

I want to try to separate the different security models to the greatest possible extent, so that decisions made for one model do not spill over to another model unless that is clearly intended.

Separability will make it possible to extract just the files needed for a particular model and, assuming that the model is used in the proper places, determine whether the model appears to be consistent and correctly implemented.

Therefore, each model consists of five parts:

In addition, new utility methods may be defined in OpSecurityManager, and code in the various models may be changed to merge common utility functions. But complex policy should not be encoded in the utility functions.

The new base classes are defined in a new header file; the implementations are defined in new source files. Thus "extraction" of a policy is physical: the files defining and implementing the policy are separate from the framework.

Memory Documentation

Is found here