TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Access Control (Apex/Summit)

Apex access control provides methods for controlling access to the objects in subsystems and views. Apex access control also provides management of UNIX permissions and groups for subsystems, views and the files within them. The chapter contains the following topics:


Access Control Point Directories

Apex designates certain types of directories as access control point directories. Access control point directories (also known as "access control points" or just "control points") provide central management of all access control properties for the directory and its children. In particular, each access control point has an owner, an associated group and an access category. The owner is the user who created the control point. The associated group is the UNIX group associated with the control point. The access category specifies the kind of access that is available to different users of the control point and determines the UNIX permissions for the control point directory and its children.

There are four different types of access control points:

Subsystem Control Points
Each subsystem is an access control point. A subsystem control point determines the access control characteristics of files directly in the subsystem as well as the Policy directory and its children. A subsystem control point also determines the access control characteristics of the version control database associated with the subsystem.
Subsystem Directory Control Points
Each user directory in a subsystem is a control point and determines the access characteristics of files in the directory. Subsystem directory control points do not have their own access categories, rather the category of the enclosing subsystem always applies to subsystem directory control points. However, subsystem directory control points may have a group that is different than the group associated with the enclosing subsystem.
View Control Points
Each view is an access control point. A view control point determines the access characteristics for all objects in the view. In particular, each view has its own owner, group and access category.
Unmanaged Directory Control Points
Each directory outside of a subsystem is an unmanaged control point. Apex does not provide any management of access control characteristics or UNIX permissions in these directories.

Note: In the following sections the access control characteristics of control points will be described. It should be remembered that these descriptions always apply to the control point and to all children of the control point that are not nested in another control point.


Owners

Each access control point directory has as its owner the user who created the control point. The control point owner is identical to the UNIX owner of the control point directory. The owner of a control point always has full access to the control point and its children.

Depending on the access category of the control point, the owner may or may not also be the UNIX owner of all of the children of the control point.


Associated Groups

Each access control point has an associated group that is identical to the UNIX group associated with the control point. All children of the control point (except for other control points) will normally have the same UNIX group as the control point. However, it is possible in some circumstances that children of a control point will have a different UNIX group. In particular, when the access category is user_only it is sometimes the case that the group of an object in the control point will be different than that of the control point. However, in the case of access category user_only the group is unimportant because users in the associated group (other than the owner) have no access to the control point or its children.


User Classes and Access Kinds

As is usual for UNIX, control point access is based on the class of the user with respect to the control point. The possible user classes are:

Owner
signifies that the current user is the owner of the control point.
Group member
signifies that the current user is a member of group associated with the control point.
Other user
specifies that the user is neither the owner nor a member of the associated group.

There are several different kinds of access that may be specified for the different user classes. The kind of access determines the UNIX permissions for the control point and the ability of users in the different user classes to apply Apex operations to the control point.

The different kinds of access for control points are:
Full access
specifies that the user has the ability to read and write files, create new files, search directories and to apply all Apex operations to the control point and its children. The owner of a control point always has full access to the control point.
Read-only access
specifies that the user has the ability to read files, search directories and apply read-only Apex operations to the control point and its children.
No access
specifies that the user has no ability to access files or apply Apex operations to the control point.

The actual access that a user has to a control point is determined by the user class of the user with respect to the control point and the kind of access that is provided to that user class. For example, if a user is not the owner but is in the group associated with the control point then the user will have one kind of access. If the user is not in the group then another kind of access is possible.

The access kinds for different user classes are not specified directly but rather are specified as part of the control point's access category.


Access Categories

The access category of a control point specifies the kind of access that is available to all user classes including the owner, members of the associated group and other users. Each control point has an access category with the exception of subsystem directory control points which have the same category as their enclosing subsystems.

The access categories and their characteristics are defined below:

Since an access category describes the kind of access for each kind of user, an access category (with minor exceptions) is sufficient to determine the UNIX permissions for a control point and its children. The UNIX permission settings for a checked out file associated with the different access categories are described in Table 2 .

Table 2 Access Categories and UNIX Permissions
Access Category
Directory Permissions
File Permissions
User_Only


User_Group


User_Public


Group_Only


Group_Public


Public


Unmanaged
unspecified
unspecified

The permissions described in Table 2 are subject to the following exceptions:

1 . Apex removes write permissions for checked in files.

2 . Files may have execute permission set by users as required. However, Apex will not retain execute permission for a specific user class unless read access is also provided for the user class.

3 . On some platforms the permissions on symbolic links may not match the values specified for the access category. However, the data referenced by the symbolic link will always have permissions that appropriate for the access category.

Special Permissions for Implementation Directories

Several of the implementation directories in views have special permissions in order to facilitate high-level operations. In these implementation directories write permission is granted to users who would normally only have read permission. In particular, for each of the special implementation directories listed below, write permission is granted to the associated group if the access category is User_Group or User_Public and write permission is granted to other users when the access category is User_Public or Group_Public. The implementation directories with special permissions are:


Access Control Checks

When a command is executed Apex checks that the current user has sufficient access. These checks involve the following steps for each object involved in the operation:

1 . The required kind of access to the object is determined. This will determine whether full access or read-only access is required.

2 . The access control point of the object is determined.

3 . The class of the user with respect to the control point is determined. This will specify whether the user is the owner, a member of the associated group or neither.

4 . The access category of the control point is determined and checked to see if the category grants the required access to the user. If access is granted then the operation proceeds otherwise the operation is not allowed.

In this section the general access control requirements for Apex commands are described.

Creation of Objects

Creation of objects in subsystems or views requires full access to the enclosing control point. When objects are created based on models or prototype files at least read-only access is required to the models or prototype files.

Common Operations

Copying requires at least read-only access to the source object and full access to the parent control point of the destination object.

Deletion requires full access to the deleted object and to its parent. In particular, when a control point is being deleted, full access is required to that control point and to the enclosing control point.

Specialized Operations

Copying views requires at least read-only access to the source views and full access to the subsystems in which the new views are created.

Deletion of specialized objects such as export sets or histories requires full access to the control point containing the object. Also deletion of histories requires full access to any views which reference the histories.

Changing the Access Category of an Existing View

There is no GUI function to change the access category for an existing view, but the change can be done using two simple steps.

1 . In your view, edit the file .Rational/View_Control/View_Properties.prop.

The first line will look something like:

2) Now run Control > Maintenance > Maintain on the view and check the Unix Permissions Maintenance button (and other buttons if you wish).

Version Control

Commands that are used to create new versions require full access to the subsystem and full access to the view in which the user is working. These commands include:

Commands that add information to the version control database independent of any view require full access to the subsystem. These commands include:

Commands that change the versions associated with a view require full access to the view and at least read-only access to the subsystem. These commands include:

Commands that display information require read-only access to the subsystem and the view. These commands include:

Importing and Exporting

Changing imports requires full access to the view being updated. Refreshing imports is possible with just read-only access. Also at least read-only access is required to the views being imported.

Exporting requires full access to the view.

Compilation and Build Management

For Ada, initiating a compilation operation in a view requires full access to the view. For example, you may only code or clean a view if you have full access to that view. In addition, if a read-only view is imported into a view to which you have full access then compiling the importer may also involve compiling exported units in the imported view. This type of closure compilation only requires read access to the imported view.

For C/C++, compilation and build management operations in C++ views require full access to the view.

Compilation also requires at least read-only access to imported views.

Modeling

Remodelling requires full access to the view being remodelled and at least read-only access to the model view.

Maintenance

Maintenance operations require at least read-only access in order to check and full access if any objects are to be repaired.

Access Control and Development Styles

In this section several examples are presented of how the access control capabilities of Apex can be used to support different development styles.

Cooperative Development

In a cooperative development style all users responsible for any aspect of a system under development are provided with full access to the entire system. The access control characteristics of a cooperative development style are:

When the access control characteristics are set as described above, any user in the development group may make changes and compile in any of the subsystems and views. This style can be made more restricted by limiting the access that some users have to some of the views. Some restricted development styles are described in the next sections.

Private Views

Typically developers working in Apex subsystems will have personal views in which they work. In the cooperative development style, although such personal views may be intended for a single user, there is no protection against other users also working in those views. However, access to personal views can be limited to a single user. Views which provide full access to a single user and no others are called private views. Private views can be created by the following steps:

When private views are set up in this way only the owner may edit and check in/out in the view. As in the cooperative development style, we assume that there is a development group associated with all subsystems and views and that the owners of private views are members of the group so that they can create new versions in the version control database.

Managing Release Views

Usually special views are designated for use in system integration and release tasks. For these views it may be desirable to limit access to a group of users responsible for these tasks. Views with these access requirements can be set up in the following way:

When release views are set up in the way only the users in the release group may update the contents of the release views and compile in those views. Other users are allowed read access to the release views and in particular may accept changes from the release views when they need to update their personal views to match the latest release.


Access Control Commands

The following commands have significant effects on the access control characteristics of Apex objects:


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS