Security
From a security point of view, PASE for i programs are subject to the same security restrictions as any other program on the IBM® i operating system.
To run an PASE for i program on the IBM i operating system, you must have authority to the AIX® binary files in the integrated file system. You must also have the proper level of authority to each of the resources that your program accesses, or the program will receive an error when you attempt to access those resources.
The following information is particularly important when you run PASE for i programs.
User profiles and authority management
System authorization management is based on user profiles that are also objects. All objects created on the system are owned by a specific user. Each operation or access to an object is verified by the system to ensure the user's authority. The owner or appropriately authorized user profiles can delegate various types of authorities to operate on an object to other user profiles. Authority checking is provided uniformly to all types of objects.
The object authorization mechanism provides various levels of control. A user's authority can be limited to exactly what is needed. Files stored in the QOpenSys file system are authorized in the same manner as UNIX files. The following table shows the relationship between UNIX permissions and the security values used on IBM i database files. On the IBM i operating system, *OBJOPR is use object authority; *EXCLUDE is no authority. *READ, *ADD, *UPD, *DLT, and *EXECUTE are data authorities. You need *EXECUTE authority (and sometimes *READ authority) to a file to run it as an PASE for i program.
| UNIX permission | *OBJOPR | *READ | *ADD | *UPD | *DLT | *EXECUTE |
|---|---|---|---|---|---|---|
| r(read) | X | X | ||||
| w(write) | X | X | X | X | ||
| x(execute) | X | X | ||||
| No authority |
User profiles in PASE for i
On the IBM i operating system, authentication information is stored in individual profiles rather than in files such as /etc/passwd. Users and groups have profiles. All of these profiles share one name space, and each profile must have a unique monocase name. If you pass a lowercase name to the getpwnam() or getgrnam() API, the system converts the name strings to the expected case.
If you call getpwuid() or getgrgid() to get the profile name returned, it will be in lowercase, unless you set the PASE for i environment variable PASE_USRGRP_LOWERCASE=N, which returns the result in uppercase.
Every user has a user identification (UID). Every group has a group identification (GID). These are defined according to the Portable Operation System Interface X (POSIX) 1003.1 standard. The two numeric spaces are separate, so you can have a user with a UID of 104 and a group with a GID of 104 that are distinct from each other.
The IBM i operating system has a user profile for the security officer, QSECOFR, that has a UID of 0. No other profile can have the UID of 0. QSECOFR is the most privileged profile on the system and, in that sense, acts as the root user. However, the IBM i operating system also provides a set of specific privileges that can be assigned to individual users by system administrators. For example, one of these privileges, *ALLOBJ, overrides the discretionary access control for file access, which is a typical use of root privileges on operating systems, such as AIX and Linux.
In a ported application that uses root access, it is probably a better security practice to create a specific user profile for the application user that can be given *ALLOBJ authority. Therefore, you can avoid the use of QSECOFR, which has much more privilege than is needed by the single application. Unlike operating systems, such as AIX or Linux, the IBM i operating system does not require group membership for users. The GID of 0 for a user profile on the IBM i operating system means no group assigned rather than referring to a group with more privileges.
IBM i security relies on integrated security built into the system. All accesses to objects must pass a security check. The security check is done with respect to the user profile for which the process runs at the time of the access.
PASE for i relies on giving each process a separate address space to maintain integrity and security. If a resource is not available in your PASE for i address space, you cannot access it. File system security prevents someone from loading a resource into their address space without proper authorization. After it is in the address space, the resource is available to the process regardless of the identity under which the process is running.
An PASE for i program uses system calls to request system functions. System calls for an PASE for i program are handled by the IBM i operating system. This interface gives PASE for i programs only indirect (and safe) access to system internals.