next up previous
Next: Lattice-based Policies Up: An Authorization Framework for Previous: Authorization Walk-through

Managing the EACL using the Prospero Directory Service

We have mentioned in section 2 that PRM deals with scalability issues by splitting the task of managing the resources across the three types of managers. Our goal in designing a mechanism for the management of the EACL files was to enable easy sharing of a default authorization policy among node managers, while allowing customization of the policy at the level of individual hosts.

We use the Prospero Directory Service [4] to store the information associated with the EACL files. The EACL files themselves are objects stored in the Prospero Directory Service.

The following scenario shows how the management of the files is accomplished:

1) The administrator of the domain whose resources are managed by a system manager running on host A creates an EACL file describing the default authorization policy which applies to the domain.

2) The administrator registers with the Prospero server. We supply a script which takes as input the location of the EACL file and creates a Prospero object representing a link to the EACL file, together with two attributes for the link:

SYSTEM_MANAGER A

EACL_DEFAULT True

3) If the administrator of a particular host B in the domain managed by A wants to specify a local authorization policy different from the default one, a similar procedure is followed, except that the link to the local EACL file is created with the following attributes:

NODE_MANAGER B

EXTEND_DEFAULT Prepend/Append/Replace (Prepend if the local policy extends the default policy, Append if the local policy is appended to the default and Replace if the local policy completely replaces the default)

4) When a system manager is contacted by a job manager with a request for resources, it first authenticates the user, as was explained in the authorization scenario in section 5. Before requesting resources from a node manager running on a particular node B, the system manager retrieves the EACL file associated with that node by looking for a link with attribute NODE_MANAGER = B. If no such link is found, the default EACL file provided for the domain will be used. The file is retrieved by looking for a link with attributes SYSTEM_MANAGER = A and EACL_DEFAULT = True. If a link with NODE_MANAGER = B is found, then a second query is issued for the value of the attribute EXTEND_DEFAULT. If the value is Prepend or Append, the system manager will have to retrieve the default EACL file first, and then prepend or append it the contents of the EACL file for node B. If the value is Replace, then only the EACL file for node B will be retrieved and used.

5) After retrieval of the EACL file, evaluation of the restrictions listed in the file follows, as detailed in the authorization scenario from section 5. If all the restrictions are met, the job manager is allowed to use the resources on that particular host.

6) During the execution of tasks on a particular host, the node manager periodically checks whether the task is abiding to the limits imposed on the local resources. If it is not, then the task is interrupted and the job manager is notified.


next up previous
Next: Lattice-based Policies Up: An Authorization Framework for Previous: Authorization Walk-through
Tatyana Ryutov 2002-06-25