IMS::ReleaseMgr::Access - A small module to abstract the Access Control Lists


    use IMS::ReleaseMgr::Access qw(ACL_get ACL_error);

    $acl = ACL_get('');
    unless (defined $acl)
        die ACL_error;


The access control lists (ACLs) are the means by which the client-side release manager tools mediate which users have permission to release which projects. Access is managed on a per-host-per-project basis; that is, a person may be given permission to release project "commcenter" on the host without being given permission to release other projects on that same host, or even be given permission to release that particular project on other, different hosts.

The ACLs are currently implemented as plain-text files using lines that are colon-delimited. Future plans include moving this information to a database platform such as Oracle.


The following subroutines are provided and may be imported. None are imported by default, so a program using this library needs to explicitly specify which components are to be used:

ACL_dir [ $dir ]

Return the current directory in which the IMS::ReleaseMgr::Access library expects to find the host files. This is used whenever a read request is made, unless the parameter passed to ACL_get (see below) is an absolute path. If ACL_dir is passed a string argument, then the default directory is set to the new value, and the return value is the old value.

ACL_get $host

Read the ACL specified in the parameter $host. If $host is an absolute file pathname, it is opened directly. Otherwise, the current value of ACL_dir is prepended to it. The return value is a hash reference whose keys are the names of the projects specified in the ACL file. Should an error occur, the special value undef is returned, and the error message may be retrieved via the ACL_error routine described below. See the section on FORMAT for a description of the ACL data format.

ACL_put $acl, $host

This is not yet implemented. In the future, it will dump the ACL specified in the parameter $acl to a host file specified in $host. At present, it immediately returns an error value of 0 with a message in ACL_error.


This returns the current value of the internal error message string. All operations clear the error string upon success, so there is no danger of getting a stale error message.


When an ACL is returned by the "read" operation, it is expressed as a hash table reference whose keys are the names of projects that can be released to the specified host. The value that corresponds to each of these keys is also a hash table reference with the following key/value pairs:


The project name. This name need only be unique within the scope of a given host ACL file. It is not recommended that the same name be used to refer to different projects on different hosts, however. This is the name by which users refer to the project for populate, stage and release operations.


A list of one or more users permitted to release the project. The names (if there are more than one) are comma-separated (no intervening whitespace between names). This list is only consulted for the release operation. Anyone can still perform the other operations, provided they have sufficient permissions on the relevant files.


A list of e-mail addresses to which notification of a release is sent. This may be blank if so desired. These addresses are also attached to the outgoing release package so as to be included on any e-mail sent by the server-side release tools.


The name (generally not the user ID) of the person currently considered the project "owner".


The email address for the owner.


This is an optional sixth field in the ACL file. It is not used anywhere programatically, but servers to make the ACL file itself a little more understandable to the casual reader.

To access the USERS field for a project $project, one would do:

    $users = $acl->{$project}->{USERS};

(Assuming that $acl is the valid return value from a call to ACL_get).


Randy J. Ray <>


IMS::ReleaseMgr, IMS::ReleaseMgr::Utils, perl