![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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
- Owners
- Associated Groups
- User Classes and Access Kinds
- Access Categories
- Access Control Checks
Access Control Point DirectoriesApex 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:
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.
OwnersEach 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 GroupsEach 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 KindsAs 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:
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:
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 CategoriesThe 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:
- User_Only or Private
Specifies that the owner has full access to the control point while other users are to have no access.
The owner of the control point will also be the owner of all children of the control point.
- User_Group
Specifies that the owner of the control point is to have full access while the group associated with the control point is to have read-only access. Users who are not the owner and who are not in the associated group have no access.
The owner of the control point will be the owner of all children of the control point.
- User_Public
Specifies that the owner of the control point is to have full access while all other users are to have read-only access. The owner of the control point will be the owner of all children of the control point.
- Group_Only
Specifies that the owner and users in the associated group are to have full access while other users are to have no access.
- Group_Public
Specifies that the owner and users in the associated group are to have full access while other users are to have read-only access.
- Public
Specifies that all users are to have full access.
- Unmanaged
Specifies that access to the control point is not managed by Apex.
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:
- .Rational/Build_Control (C/C++ only)
- .Rational/Compilation
- .Rational/Imports_Control
- .Rational/Locks_Control
Access Control ChecksWhen 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:
VP.ACCESS_CATEGORY: group_public
Change "group_public" to "user_public" or some other value (see Access Categories) and save the file.
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:
- check_in
- check_out
- abandon
- control (when a new version is created)
- set_history (when a new version is created)
- migrate_history
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:
- control (when a new version is not created)
- set_history (when a new version is not created)
- set_version
- accept_changes
- uncontrol
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:
- A group is created containing all users who are to work on the system under development. This group is called the development group.
- All subsystems and views in the system are created with their associated group set to the development group.
- All subsystems and views in the system have their access category set to group_public or group_only.
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:
- The user who is to be working in the private view must be the owner of the view and therefore must create the view.
- The access category of the view should be set to either user_only, user_group, or user_public depending on the level of access that is to be allowed to other users. Typically, user_group would be used in order to allow other users in the development group the ability to read and accept changes from the private view.
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:
- A group is created containing all users who are to be responsible for integration and release tasks. This group will be called the release group. All of the users in the release group should also be in the development group that was described earlier.
- Views are created for release purposes by some user in the release group. The group associated with these views is designated to be the release group. The access category for these views is set to group_public.
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 CommandsThe following commands have significant effects on the access control characteristics of Apex objects:
- create_subsystem
Currently, there are no options to specify access control characteristics for subsystems. All subsystems are created with a group inherited from the enclosing directory and the access category of all subsystems is set to group_public.
- create_working
create_releaseBoth of these commands have options which allow a specific access category and group to be specified at the time of view creation. The default option settings create views with access category group_public and a group that is inherited from the enclosing directory. In addition, there are option settings that allow the access category and group to be the same as those of the specified model view.
- copy_view
This command has options which allow a specific access category and group to be specified at the time of the copy. The default option settings create views whose access category is the same as that of the source view and a group that is inherited from the enclosing directory. In addition, there are option settings which allow the access category and group to be the same as those of the specified model view.
- remodel
When the kind of a release view is changed to frozen full access is removed for all user classes.
- maintain
When the -permissions option is set the command will check that the UNIX permissions for all objects are consistent with the access category and that the associated group for all objects is the same group as that of the control point. If any problems are found they are reported and repaired unless the -check option is set.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |