$Id$
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.
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:
OpSecurityManager::Operation.
OpSecurityManager, defining the
security checker methods and any auxiliary code for the new
commands.
OpSecurityManager::CheckSecurity() for
each new command name, dispatching to methods defined in the
new base class for OpSecurityManager.
OpSecurityContext, defining any
additional fields the model needs in its context data structure.
documentation directory describing the
model, and a link from this file to that file in the list of models
above.
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.
Is found here