When a user tries to enter the OpenExtensions VM shell, CA ACF2 for VM verifies that he is an OpenExtensions VM user before the system initializes the shell. CA ACF2 for VM also verifies that the user associated with a program trying to access OpenExtensions VM resources is an OpenExtensions VM user before allowing the access to the requested resource.
To define a user as an OpenExtensions VM user, you must:
OpenExtensions VM recognizes users by their assigned user identification (UID) and group identification (GID) numbers. (The UID referenced in relation to OpenExtensions VM is not the CA ACF2 for VM User Identification String (UID)). UIDs and GIDs can have numeric values of zero to 2,147,483,647. To set the UID for a user, create a USER Profile record. The new OEVM segment of the USER Profile record defines a user's UID, the user's home directory, the initial program that the user will run, and the initial Byte File System for the user. The initial program is generally the shell program that the user invokes.
For more information about creating USER Profile records, see CA ACF2 for VM Records for OpenExtensions VM.
A superuser is a special user under OpenExtensions VM. The superuser is a trusted user who can maintain the OpenExtensions VM system and administer security in the BFS. A superuser's UID has a zero. Use caution when assigning the superuser authority. A superuser passes all security checks, meaning the superuser can access any file in the file system. This type of authority is similar to an unscoped security officer. However, assigning superuser authority to a user does not give the user any added authority outside of OpenExtensions VM.
OpenExtensions security is based on user and group ownership of files and processes. CA ACF2 for VM uses the GROUP field of the logonid to assign the user to an OpenExtensions VM group. Users can also specify the group they want to be associated with at system entry time. A new GROUP Profile record assigns the GID to the group. For more information on GROUP Profile records, see CA ACF2 for VM Records for OpenExtensions VM.
We recommend that you assign a unique GID to each group. If you assign the same GID value to multiple groups, the groups share ownership of and access to the same files. This can cause unreliable results. For example, if you assign multiple groups the same GID and a Query Group Database service request is made, only one group name is returned in response to the request. CA ACF2 for VM searches its cross‑reference tables and returns the first group that matches the GID. It does not return all the groups associated with that GID, nor can it distinguish the specific group that you intend to make the request for.
Under OpenExtensions VM and CA ACF2 for VM, a user is a member of the group defined in the GROUP field of his logonid and a member of any group that he has access to through a resource rule. A user can change to another group with the OpenExtensions VM setgid() or setegid() functions as with the shell newgrp command. These groups are called supplemental groups.
To grant a user access to a group other than the group defined in his logonid record, create a TYPE(PGR) resource rule. The $KEY of the rule identifies the one‑ to eight‑character group name. This field is maskable, but you must create an entry for the PGR type code in the RESTYPE VMO record. Following is an example of a resource rule that grants access to group OEVMGRP to users in the payroll and audit departments:
$KEY(OEVMGRP) TYPE(PGR) UID(*****pay‑) ALLOW UID(*****aud‑) ALLOW
For more information about defining TYPE(PGR) resource rules, see Recource(PGR) POSIX Group Rules.
For more information about setting the owner, group, and other permissions for a file, see the OpenExtensions for VM User's Guide.
|
Copyright © 2009 CA Technologies.
All rights reserved.
|
|