Previous section.

Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group

MDS Administration

MDS administration is partially platform-dependent. The general activities of MDS administration are described in this chapter. Specific activities that can be defined in a platform-independent are defined for use on all platforms.

MDS Installation

The MDS service is installed separately from any particular instance of CDSA. However, CDSA installation is dependent on MDS. The CDSA installation scripts should check for MDS availability before proceeding.

There should be a single MDS service per system. Conventions for locating MDS application information must be defined on a per-platform basis. The MDS application attributes that should be available to applications include:

CDSA-related installation programs use the MDS registry information to discover if the appropriate MDS is available on the system. It may be necessary to upgrade MDS binaries or update MDS schema before CSSM, EMM, or service provider modules can be installed. For this reason, a CDSA installation package must include MDS installation programs.

The MDS installation program creates the databases and relations defined in this specification.

Elective module manager (EMM) installation programs may contain MDS installation programs that update the MDS schema to accommodate EMM service providers.

General Access Control over MDS Databases

Update access to MDS data may require satisfying an access control policy defined by the MDS provider. The mechanisms for enforcing privileged access include:

Privileged Application

Administrative tools that contain access permissions information in their manifest constitute privileged applications. If MDS interfaces are not statically bound to the administrative application then the MDS library must authenticate the manifest of the privileged application. Static binding removes the need for bilateral authentication of an administration application with an MDS library and is the desired approach. This technique should be combined with other access mechanisms to extend access privilege semantics to file system access control mechanisms.

File Permissions

File permissions can be established at database creation time. Default file permissions and file owners are set explicitly by the MDS provider. The file permissions are enforced at database open. The database access flags supplied with the DbOpen call are mapped to file system permission bits

Mapping the DL database access flags to file permissions is platform-specific. If the host operating system supports User, Group, Other privileges controlling Read, Write, and Execute permission bits, the following table suggests how the DL access flags, of type CSSM_DB_ACCESS_TYPE, could be mapped on a UNIX* platform.

DL Access Flags Permission Bits Process Privilege
CSSM_DB_ACCESS_READ r-- other
CSSM_DB_ACCESS_WRITE rw- group
CSSM_DB_ACCESS_PRIVILEGED rw- user
CSSM_DB_ACCESS_ASYNCHRONOUS N/A group

Read-only access is granted to all processes. This enables the DbQuery interfaces. Read/Write access it granted to installation programs and services handling dynamic service provider insert and remove events. Write access is enabled for DbInsert, DbUpdate and DbDelete. An administration application that updates the MDS schema or reorganizes the database must own the database files to obtain privileged access. This, along with read/write privileges, allows exclusive access to the MDS database. When opened with CSSM_DB_ACCESS_PRIVILEGED, no other processes may open the database. In order to make changes to the MDS schema, the database needs to be opened with CSSM_DB_ACCESS_PRIVILEGED; in this case, the user/application has also the rights to query and insert/delete/update records in any user relation.

A privileged user can set use of CSSM_DB_ACCESS_ASYNCHRONOUS. It is MDS administration policy that determines the degree of perceived risk due to cached write operations. By default CSSM_DB_ACCESS_ASYNCHRONOUS is enabled.

Administrator ACLs

An additional degree of protection may be achieved through use of ACLs. The CSSM_RESOURCE_CONTROL_CONTEXT structure may be used in conjunction with CSSM_DB_ACCESS_WRITE and/or CSSM_DB_ACCESS_PRIVILEGED to control which entities are permitted to update MDS databases.

Click here to return to the publication details.

Contents Next section Index