HP 3000 Manuals HP 3000 Manuals
Traditional Mechanism for File Security [REV BEG] The traditional security mechanism (file access matrix and lockwords) associates with each account, group, and individual files a set of security provisions that specifies any restrictions on access to the files in that account or group, or to that particular file.
NOTE These provisions apply to disk files only. If a file is protected by the traditional security mechanism and by an ACD definition, the ACD definition overrides the traditional security mechanism. ACD security mechanism are discussed at the beginning of this chapter under "Access Control Definition Security (ACD)" .
[REV END] These restrictions are based on two factors: * modes of access--reading, writing, or saving, for example. * types of user--users with account librarian (AL) or group librarian (GL) capability, or creating users, for example, to whom the access modes specified are permitted The security provisions for any file describe what modes of access are permitted to which users of that file. Specifying and restricting file access by access mode When a program opens or creates a file, it can define the way that the file can be accessed by specifying a particular access mode (such as Read-only, Write-only, Update, and so forth) for the file. These specifications apply to files on any device and can be changed or overridden only by yourself, as the creator of the file. They are discussed in the following paragraphs. In addition, for files on disk, a program can also restrict access so that only one access attempt (HPFOPEN/FOPEN call) or process (running program) can open it at one time, or can allow it to be shared among several accessors. The access types that can be specified by a program are listed in Table 13-3 . When specifying the access mode for a file, it is important to realize where the current end-of-file is before and after the file is opened, and where the logical record pointer indicates that the next operation will begin. These factors depend upon the access mode that you select. Because they are best explained by example, the effects of each access mode upon these factors are summarized in Table 13-4 for a sample file. This file contains 10 logical records of data (numbered 0 through 9). The table shows that the current end-of-file (EOF) lies at Record 10 before the file is opened, indicating that if another record were appended to the file, that would be the eleventh record. When you open the file in the Write-only mode, however, all records presently in the file are deleted and the logical record pointer and current EOF move to record 0. Now when you write a record to the file, this will be the first record in that file. Suppose that you are running a program that opens a magnetic tape file for Write-only access, but you wish to append records to that file rather than to delete existing records. You can override the programmatic specifications by using the FILE command to request Append access to the file, as follows: FILE TASK; DEV=TAPE; ACC=APPEND RUN PROGN \ Requests append access Table 13-3. Traditional File Access Mode Types ----------------------------------------------------------------------------------------------- | | | | | ACCESS MODE | :FILE | DESCRIPTION | | | PARAMETER | | | | | | ----------------------------------------------------------------------------------------------- | | | | | Read-only | IN | Permits file to be read but not written on. Used for | | | | device files, such as card reader and paper tape reader | | | | files, as well as magnetic tape, disk, and terminal | | | | output files. | | | | | | Write-only | OUT | Permits file to be written on but not read. Any data | | | | already in the file is deleted when the file is opened. | | | | Used for device files, such as card punch and line | | | | printer, as well as tape, disk, and terminal output | | | | files. | | | | | | Write-SAVE | OUTKEEP | Permits file to be written on but not read, allowing you | | | | to add new records both before and after current | | | | end-of-file indicator. Data is not deleted, but a | | | | normal write replaces it. | | | | | | Append-only | APPEND | Permits information to be appended to file, but allows | | | | neither overwriting of current information nor reading | | | | of file. Allows you to add new records after current | | | | end-of-file indicator only. Used when present contents | | | | of file must be preserved. | | | | | | Read/Write | INOUT | Permits unrestricted input and output access of file; | | | | information already on file is saved when the file is | | | | opened. (In general, combines features of IN and | | | | OUTKEEP.) | | | | | | Update | UPDATE | Permits the use of FUPDATE intrinsic to alter records in | | | | file. Record is read into your data stack, altered, and | | | | rewritten to file. All data already in file is saved | | | | when the file is opened. | | | | | ----------------------------------------------------------------------------------------------- Suppose that you run a program that opens a disk file for write-only access, copies records into it, and closes it as a permanent file. Under the standard file system security provisions, the access mode is automatically altered so that the file permits the read, write, and append access modes (among others). Now, suppose that you run the program a second time, but wish to correct some of the data in the file rather than delete it. You could use the FILE command to override the programmatic specification, opening the file for update access: FILE REPFILE; ADD=UPDATE RUN PROGN \ Requests update access Table 13-4. Effects of Access Modes ------------------------------------------------------------------------------------------------- | | | | | | ACCESS | CURRENT | LOGICAL | EOF | | MODE | EOF | RECORD | AFTER | | | | POINTER | OPEN | | | | | | ------------------------------------------------------------------------------------------------- | | | | | | Read-only | 10 | 0 | 10 | | | | | | | Write-only | 10 | 0 | 0 | | | | | | | Write-SAVE | 10 | 0 | 10 | | | | | | | Append | 10 | 10 | 10 | | | | | | | Read/Write | 10 | 0 | 10 | | | | | | | Update | 10 | 0 | 10 | | | | | | ------------------------------------------------------------------------------------------------- Consider a program that reads input from a terminal (file name INDEV) directs output to a line printer (OUTDEV). You can redirect the output so that it is transmitted to the terminal by entering: FILE INDEV; DEV=TERM; ACC=INOUT <---- Respecifies INDEV for both input and output access FILE OUTDEV=*INDEV <---- Equates INDEV to OUTDEV RUN PROGO <---- Runs program Specifying and restricting file access by type or user Restrictions on who can access a file are established when the file is created according to the default prescribed for the group and account where the file resides. The capabilities of the user who accesses a file may determine the security restrictions that apply to him. The types of users recognized by the MPE/iX security system, the mnemonic codes used to reference them, and their complete definitions are listed in Table 13-5 . Table 13-5. User Type Definitions (Traditional Security) ---------------------------------------------------------------------------------------------- | | | | | USER TYPE | MNEMONIC | MEANING | | | CODE | | | | | | ---------------------------------------------------------------------------------------------- | | | | | Any User | ANY | Any user defined in the system; this includes all | | | | categories defined below. | | | | | | Account Librarian | AL | User with Account Librarian capability, who can | | User | | manage certain files within his account that may or | | | | may not all belong to one group. | | | | | | Group Librarian User | GL | User with Group Librarian capability, who can | | | | manage certain files within his home group. | | | | | | Creating User | CR | The user who created this file. | | | | | | Group User | GU | Any user allowed to access this group as his logon | | | | or home group, including all GL users applicable to | | | | this group. | | | | | | Account Member | AC | Any user authorized access to the system under this | | | | account; this includes all AL, GU, GL, and CR users | | | | under this account. | | | | | ---------------------------------------------------------------------------------------------- Users with system manager or account manager capability bypass the standard security mechanism. A system manager has unlimited file access to any file in the system (R,A,W,L,X:ANY), but can save files only in his own account (S:AC); an account manager user has unlimited access to any file within the account (R,A,W,L,X,S:ANY). One exception is that in order to access a file with a negative file code (a privileged file), the account manager must also have the privileged mode (PM) capability. The user-type categories that a user satisfies depend on the file he is trying to access. For example, a user accessing a file that is not in his home group is not considered a group librarian for this access even if he has the group librarian user attribute.
NOTE In addition to the above restrictions in force at the account, group, and file level, a file lockword can be specified for each file. Users then must specify the lockword as part of the file name to access the file.
The security provisions for the account and group levels are managed only by users with the system manager and the account manager capabilities respectively, and can only be changed by those individuals. Account-level security. The security provisions that broadly apply to all files within an account are set by a system manager user when creating the account. The initial provisions can be changed at any time, but only by that user. At the account level, five access modes are recognized: * reading (R) * appending (A) * writing (W) * locking (L) * executing (X) Also at the account level, two user types are recognized: * any user (ANY) * account member (AC) If no security provisions are explicitly specified for the account, the following provisions are assigned by default: * For the system account (named SYS), through which the system manager user initially accesses the system, reading and executing access are permitted to all users; appending, writing, and locking access are limited to account members.
NOTE Symbolically, these provisions are expressed as follows: (R,X:ANY;A,W,L:AC) In this format, colons are interpreted to mean, "...is permitted only to..." or "...is limited to...." Commas are used to separate access modes or user types from each other. Semicolons are used to separate entire access mode/user type groups from each other.
* For all other accounts, the reading, appending, writing, locking, and executing access modes are limited to account members (R, A, W, L, X: AC). Group-level security. The security provisions that apply to all files within a group are initially set by an account manager user when creating the group. they can be equal to or more restrictive than the provisions specified at the account level. (The group's security provisions also can be less restrictive than those of the account--but this effectively results in equating the group restrictions with the account restrictions, since a user failing security checking at the account level is denied access at that point and is not checked at the group level.) The initial group provisions can be changed at any time, but only by an account-managing user for that group's account. At the group level, six access modes are recognized: * reading (R) * appending (A) * writing (W) * locking (L) * executing (X) * saving (S) Also at the group level, five user types are recognized: * any user (ANY) * account librarian user (AL) * group librarian user (GL) * group user (GU) * account member (AC) If no security provisions are explicitly specified, the following provisions apply by default: * For a public group (named PUB), whose files are normally accessible in some way to all users within the account, reading and executing access are permitted to all users; appending, writing, saving, and locking access are limited to account librarian users and group users (including group librarian users). (R, X: ANY; A, W, L, S: AL, GU). * For all other groups in the account, reading, appending, writing, saving, locking, and executing access are limited to group users. (R, A, W, L, X, S: GU). File-level security. When a file is created, the security provisions that apply to it are the default provisions assigned by MPE/iX at the file level, coupled with the user-specified or default provisions assigned to the account and group to which the file belongs. At any time, however, the creator of the file (and only this individual) can change the file-level security provisions, as described in the following pages; thus, the total security provisions for any file depend upon specifications made at all three levels, the account, group, and file levels. A user must pass tests at all three levels--account, group, and file security, in that order--to successfully access a file in the requested mode. If no security provisions are explicitly specified by the user, the following provisions are assigned at the file level by default: * For all files, reading, appending, writing, locking, and executing access are permitted to all users. (R, A, W, L, X: ANY). Because the total security for a file always depends on security at all three levels, a file not explicitly protected from a certain access mode at the file level may benefit from the default protection at the group level. For example, the default provisions at the file level allow the file to be read by any user--but the default provisions at the group level allow access only to group users; thus, the file can be read only by a group user. In summary, the default security provisions at the account, group, and file levels combine to result in overall default security provisions as listed in Table 13-6 . Stated another way, when the default security provisions are in force at all levels, the standard user (without any other user attributes) has: * unlimited access (in all modes) to all files in his logon group and home group * reading and executing access (only) to all files in the public group of his account and the public group of the system account The important file security rules may be defined as follows: * Users can create files in their own accounts. * Only the creator can modify a file's security. * If a lockword is present on a file, then it is required in order to access the file. * Account managers have unlimited access to the files within their accounts. * System managers have unlimited access to any file, but can save files only in their account. Table 13-6. Default Security Provisions (Traditional) ------------------------------------------------------------------------------------------------- | | | | | | FILEREFERENCE | FILE | ACCESS | SAVE ACCESS | | | | PERMITTED | TO GROUP | | | | | | ------------------------------------------------------------------------------------------------- | | | | | | filename.PUB.SYS | Any file in public | (R,X:ANY; W:AL,GU) | AL,GU | | | group of system | | | | | account | | | | | | | | | filename. groupname. | Any file in any group | (R,W,X:GU) | GU | | SYS | in system account | | | | | | | | | filename .PUB. | Any file in public | (R,X:AC; W:AL,GU) | AL,GU | | accountname | group of any account | | | | | | | | | filename. groupname. | Any file in any group | (R,W,X:GU) | GU | | accountname | in any account | | | | | | | | ------------------------------------------------------------------------------------------------- Changing security provisions of disk files The security provisions for both the account and group levels are managed only by users with the system manager capability, while group level security is managed by users with account manager capability. Even if you have only standard capabilities (IA, BA, SF), you can change the security provisions for any disk file that you have created. You do this by using the ALTSEC command, which permanently deletes all previous provisions specified for this file at the file level, and replaces them with those defined as the command parameters. This command does not, however, affect any account-level or group-level provisions that may cover the file. Furthermore, it does not affect the security provided by the lockword (if one exists). For example, suppose that you want to alter the security provisions for the file FILEX to permit the ability to read, execute, and append information to the file only to the creating user and the logon or home group users. You can do this with the following ALTSEC command: ALTSEC FILEX; (A,R,X:CR,GU) Any parameters not included in the ALTSEC command are cleared. To restore the default security provisions to this file, you would enter: ALTSEC FILEX Suppose that you have created a file named FILEZ for which you have allowed yourself program-execute access only. You now wish to change this file's security provisions so that any group user can execute the program stored within it, but only the group librarian can read and write on it. Even though you do not have Read or Write access to the file, you can still alter its security provisions by entering: ALTSEC FILEZ; (X:GU;R,W:GL) You always retain the ability to change the security provisions of a file that you have created, even when you are not allowed to access the file in any mode; thus, you can even change the provisions to allow yourself access. Suspending and restoring security provisions You may temporarily suspend the suspending and restoring security:files| security restrictions on any disk file that you create. This allows the file to be accessed in any mode by any user; in other words, it offers unlimited access to the file. You suspend the security provisions by entering the RELEASE command. (File lockword protection, however, is not removed by this command.) The RELEASE command does not modify the file security settings recorded in the system; it bypasses them temporarily. The RELEASE command remains in effect until you enter the SECURE command in this or a later job or session. To release the security provisions for the file named FILESEC in your logon group, enter: RELEASE FILESEC If the file has a lockword and that you wish to remove that as well as all account-level, group-level, and file-level security provisions, you must use the RENAME command, as well as the RELEASE command: RENAME FILESEC/LOCKSEC,FILESEC <---- Removes lockword RELEASE FILESEC <---- Removes security provisions To restore the security provisions of a file, use the SECURE command. For example: SECURE FILESEC The original security restrictions for the file will be in effect.