HPlogo Getting Started as an MPE/iX Programmer Programmer's Guide: HP 3000 Computer MPE/iX Computer Systems > Chapter 6 File System

Maintaining File Security

» 

Technical documentation

Complete book in PDF
» Feedback

 » Table of Contents

 » Index

Three security features are available on the MPE/iX system to restrict access to a single file or all disc files in a particular account or group: lockwords, the MPE/iX File Access System matrix, and access control definitions (ACDs).

Lockwords

Lockwords are file "passwords" which provide a primary level of file security by restricting access to a file to users not knowing the file's lockword. These lockwords may be assigned to a file when the file is created with the BUILD command or when the file is renamed. To delimit the lockword, enter a forward slash (/) following the file name:


   BUILD MYFILE/KEY

   RENAME MYFILE/LOCK

For additional information, refer to the MPE/iX Commands Reference Manual Volumes 1 and 2 (32650-90003 and 32650-90364).

MPE/iX File Access System

The HP 3000 system includes a set of security provisions with each account, group, and individual file. This set specifies restrictions on access to a single disc file or to all disc files in a particular account or group.

The restrictions are based on three factors:

  • Modes of access (for example, reading, writing, or saving).

  • Types of user (for example, a user with Account Librarian capability, Group Librarian capability, or a user to whom the access modes specified are permitted.)

The security provisions for any file describe the permitted access modes for various users of the file.

Specifying and Restricting File Access by Access Mode

When a program opens or creates a file, it can define the way the file can be accessed by specifying a particular access mode for the file (for example, read-only, write-only, update, and so on). These specifications apply to files on any device, and only the creator of file can change or override them.

When specifying the access mode for a file, it is important to know the location of the current end-of-file before and after the file is opened and the location of the logical record pointer that indicates where the next operation will begin. For example, the choice of the correct access mode can write a record to a file and:

  • Append it following the last record or overwrite an existing record.

  • Correct information in a file rather than delete it.

  • Redirect output from one device to another.

For detailed information on this topic, refer to Accessing Files Programmer's Guide (32650-90017).

Table 6-8 “File Access Mode Types” describes the file access mode types.

Table 6-8 File Access Mode Types

Access Mode:FILE ParameterDescription
   
Read onlyINAllows you to read a file, but not to write on it.
Write onlyOUTAllows you to write on a file, but not to read it. Any data already in the file is deleted when the file is opened.
Write (save) onlyOUTKEEPAllows you to write on a file, but not to read it. You can add new records both before and after current end-of-file indicator.
Append onlyAPPENDAllows you to append information to a file, but not to overwrite the current information or read the file. You can add new records only after the current end-of-file indicator. Used when present contents of a file must be preserved.
Input/outputINOUTAllows unrestricted input and output access of file. Information already on the file is saved when the file is opened. (In general, it combines the features of IN and OUTKEEP.)
UpdateUPDATEAllows use of FUPDATE intrinsic to alter records in a file. Record is read into your data stack, altered, and rewritten to the file. All data already in the file is saved when the file is opened.
   

 

Specifying File Access by Type or User

Restrictions on accessing a file are established when the file is created according to the default established for the group and account where the file resides.

The capabilities of a user who accesses a file can determine the security restrictions applied. Table 6-9 “User Type Definitions” describes the types of users recognized by the MPE/iX Security System, their mnemonic codes, and definitions.

Table 6-9 User Type Definitions

User TypeMnemonic CodeDescription
   
Any userANYAny user defined in the system, including all categories defined below.
Account librarian userALUser with account librarian capability, who can manage certain files within the account that may or may not all belong to one group.
Group librarian userGLUser with group librarian capability, who can manage certain files within his home group
Creating userCRUser who created this file
Group userGUAny user allowed to access this group as his logon or home group, including all GL users applicable to this group.
Account memberACAny user with authorized access under this account, including access through AL, GU, GL, and AC.
   

 

For detailed information on this topic, refer to Accessing Files Programmer's Guide (32650-90017).

The user access modes to a file are determined by four separate levels of security settings. All four levels are checked and must be passed to grant a user access to a file. The only two levels over which a standard user has control are the file and lockword levels. However, it is important for a standard user to understand all levels of the security system, since the combination of all the settings determines the user's access to the file. Figure 6-16 “Security Level for File Access” shows the security levels checked when a user attempts to gain access to a file.

Figure 6-16 Security Level for File Access

[Security Level for File Access]

The default security at account, group, and file levels are as follows:

  • Account level

            SYS (R,X:ANY;W,A,L:AC)
    
            other accounts (R,X,W,A,L:AC)
    
  • Group level

            PUB (R,X:ANY;A,W,L,S:AL,GU)
    
            other groups (R,W,A,L,X,S:GU)
    
  • File level

            (R,X,W,A,L:ANY)
    

At the group level, the MPE/iX Security System recognizes six access modes:

Reading (R) Appending (A) Writing (W) Locking (L) Executing (X) Saving (S)

It recognizes seven user types:

Any User (ANY) Account Librarian User (AL) Group Librarian User (GL) Group User (GU) Account Member (AC) System Manager (SM) Account Manager (AM)

For detailed information on this topic, refer to Accessing Files Programmer's Guide (32650-90017).

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 can change the file level security provisions. Thus, the total security provisions for a file depend on specifications made at three levels: account, group, and file. A user must pass tests at the account, group, and file levels (in 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:

Reading (R) Appending (A) Writing (W) Locking (L) Executing (X) Any User (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 detailed information on this topic, refer to Accessing Files Programmer's Guide (32650-90017).

Access Control Definitions (ACDs)

Access Control Definitions (ACDs) allow the owner of a file to specify permissions for access to a file or to a device. An ACD takes precedence over the previous access controls, namely the MPE file access matrix and lockwords. The owner of a file is any of the following: the creator of the file, the account manager (AM capability) where the file resides, or the system manager (SM capability).

A device or file can be paired with an ACD. When a user tries to acquire the device or to open the file, the system first checks the authorization list of the associated ACD. When a file is paired with an ACD, the ACD is put into its file label extension. The ACD contains a list of access modes paired with users.

Specifying and Restricting File Access

Similar to the MPE File Access System, ACDs use modes to specify the types of access to grant or refuse to users as follows:

R

read

W

write

A

append

L

lock

X

execute

NONE

none (no access)

RACD

read and copy the ACD permission file

ACDs are defined in a similar manner as file access modes. For example:



   ACD = (R,W:MGR.ACCTING, DENNIS.LEE; R:@.PAYROLL; A:@.@


MGR.ACCTING and DENNIS.LEE can read and write to the file associated with this example ACD. Any user in PAYROLL can read it, and any user on the system can append to it. If a user is not given a permission, the user does not have it.

Managing ACDs with Commands and Intrinsics

Use commands to manage ACDs interactively through the command interpreter. Use intrinsics to manage ACDs in a program.

  1. Creating ACDs

    ACDs for files may be created or owned by the system manager (SM capability), the account manager (AM capability) where the file resides, or by the creator of the file. ACDs for devices can only be created or owned by the system manager (SM capability).

    When creating a new file with the COPY, FCOPY, or RESTORE commands, use parameters to create its ACD. Use the ALTSEC command or the HPACDPUT intrinsic to create an ACD for an existing device or file.

  2. Preserving ACDs Device ACDs are not permanent objects and must be redefined every time the system is rebooted. The easiest ways to do this are to put ALTSEC commands into the SYSTART file, either directly or in a command file.

    File ACDs are permanent objects and survive a reboot. When storing files to tape, FCOPY and STORE store the files' ACDs unless you specify otherwise.

  3. Listing ACDs

    To get information about ACDs interactively, use the SHOWDEV command for devices, and the LISTFILE command for files. To get information about ACDs programmatically, use the HPACDINFO or HPACDPUT intrinsics.

    Any user can find out whether an ACD exists for a particular device or file, but only an owner, or user granted RACD (read ACD) access, can get a listing of the ACD contents.

  4. Copying ACDs

    To copy an ACD from one file to another, use the COPYACD parameter of the ALTSEC command. Only the owner or user granted RACD (read ACD) access can copy an ACD.

  5. Modifying ACDs

    To change an ACD, use the ALTSEC command or the HPACDPUT intrinsic. Only an owner can alter an ACD.

  6. Deleting ACDs

    To delete an ACD, use the ALTSEC command or the HPACDPUT intrinsic. Only an owner can delete an ACD.

  7. Migrating ACDs

    Both MPE V/E and MPE/iX support the use of ACDs. MPE/iX, however, allows more user-mode pairs than MPE V/E.

NOTE: Device ACDs shold not be migrated because they are tied to their system's configuration.

Move file ACDs between MPE V and MPE/iX by using the STORE and RESTORE commands, where COPYACD is the default.

NOTE: You must have authorization to use the COPYACD parameter of the STORE and RESTORE commands. If you are not an owner of the file and do not have RACD permission, you will get an error.

Changing Disc File Security Provisions

The security provisions for the account and group levels are managed only by users with System Manager or Account Manager capabilities, respectively. However, you can change the security provisions for any disc file you have created by using the :ALTSEC command. This does not affect any account-level or group-level provisions that may cover the file, and it does not affect the security provided by a lockword. For detailed information on this topic, refer to Accessing Files Programmer's Guide (32650-90017).

Suspending and Restoring Security Provisions

You can temporarily suspend the security restrictions on any disc file you create by using the :RELEASE command. This allows any user to access the file in any mode, thus providing unlimited access to the file. It does not remove lockword protection, and it does not modify the file security settings recorded in the system. It merely bypasses them temporarily. :RELEASE remains in effect for a file until you enter the :SECURE command in this or a later job or session or until the file is modified.

For detailed information on this topic, refer to Accessing Files Programmer's Guide (32650-90017).