Securing logical files

Resource security on the system supports field-level security of a file. You can also use logical files to protect specific fields or records in a file.

A logical file can be used to specify a subset of records that a user can access (by using select and omit logic). Therefore, specific users can be prevented from accessing certain record types. A logical file can be used to specify a subset of fields in a record that a user can access. Therefore, specific users can be prevented from accessing certain fields in a record.

A logical file does not contain any data. It is a particular view of one or more physical files that contain the data. Providing access to the information defined by a logical file requires data authority to both the logical file and the associated physical files.

Figure 1 shows an example of a physical file and three different logical files associated with it.

Figure 1. Using a logical file for security

Members of the sales department (group profile DPTSM) are allowed to view all fields, but they cannot change the credit limit. Members of the accounts receivable department (group profile DPTAR) are allowed to view all fields, but they cannot change the sales field. The authority to the physical file looks like this:

Table 1. Physical file example: CUSTMAST file
Authority	Users: *PUBLIC

Object Authorities
*OBJOPR
*OBJMGT
*OBJEXIST
*OBJALTER
*OBJREF
Data Authorities
*READ	X
*ADD	X
*UPD	X
*DLT	X
*EXECUTE	X
*EXCLUDE

The public should have all data authority but no object operational authority to the CUSTMAST physical file. The public cannot access the CUSTMAST file directly because *OBJOPR authority is required to open a file. The public’s authority makes all the data authority potentially available to users of the logical file.

Authority to the logical files looks like this:

                           
                           Display Object Authority
 
Object . . . . . . . :   CUSTINFO      Owner  . . . . . . . :   OWNAR
  Library  . . . . . :   CUSTLIB       Primary group  . . . :   *NONE
Object type  . . . . :   *FILE         ASP device . . . . . :   *SYSBAS
 
Object secured by authorization list  . . . . . . . . . . . :   *NONE
 
                        Object
User        Group       Authority
*PUBLIC                 *USE

                           
                           Display Object Authority
 
Object . . . . . . . :   CUSTCRDT      Owner  . . . . . . . :   OWNAR
  Library  . . . . . :   CUSTLIB       Primary group  . . . :   DPTAR
Object type  . . . . :   *FILE         ASP device . . . . . :   *SYSBAS
 
Object secured by authorization list  . . . . . . . . . . . :   *NONE
 
                        Object
User        Group       Authority
DPTAR                   *CHANGE
*PUBLIC                 *USE

                           
                           Display Object Authority
 
Object . . . . . . . :   CUSTSLS       Owner  . . . . . . . :   OWNSM
  Library  . . . . . :   CUSTLIB       Primary group  . . . :   DPTSM
Object type  . . . . :   *FILE         ASP device . . . . . :   *SYSBAS
 
Object secured by authorization list  . . . . . . . . . . . :   *NONE
 
                        Object
User        Group       Authority
DPTSM                   *CHANGE
*PUBLIC                 *USE

Making the group profile, such as DPTSM, the primary group for the logical file is not necessary for this authority scheme to work. However, using primary group authority eliminates searching private authorities for both the user attempting to access the file and the user’s group. Case 2: Using primary group authority shows how using primary group authority affects the authority checking process.

You can specify data authorities for logical files beginning with V3R1 of the IBM i licensed program. When a pre-V3R1 logical file is restored on a V3R1 system or later, the system converts your logical files the first time a logical file is accessed. The system gives it all data authorities.

To use logical files as a security tool, do this:

Grant all data authorities to the underlying physical files.
Revoke *OBJOPR from the physical files. This prevents users from accessing the physical files directly.
Grant the appropriate data authorities to logical files. Revoke any authorities you do not want.
Grant *OBJOPR to the logical files.