These are security considerations for the root, QOpenSys, and user-defined
file systems.
How authority works
The root, QOpenSys, and user-defined
file systems provide a blending of
IBM® i,
PC, and UNIX** capabilities both for object management and for security. When
you use the integrated file system commands from an
IBM i session
(WRKAUT and CHGAUT), you can set all the normal
IBM i object
authorities. This includes the *R, *W, and *X authorities that are compatible
with Spec 1170 (UNIX-type operating systems).
Note: The root, QOpenSys, and
user-defined file systems are functionally equivalent. The QOpenSys file system
is case-sensitive. The root file system is not. User-defined file systems
can be defined as case-sensitive. Because these file systems have the same
security characteristics, in the topics that follow the names root file system,
OOpenSys file system, and user-defined file system are used interchangeably.
When
you access the root file system as an administrator from a PC session, you
can set object attributes that the PC uses to restrict certain types of access:
- System
- Hidden
- Archive
- Read-only
These PC attributes are in addition to, not replacements for,
IBM i object authority values.
When
a user attempts to access an object in the root file system, IBM i enforces
all of the object authority values and attributes for the object, whether
those authorities are visible from the user’s interface. For example, assume
that the read-only attribute for an object is set on. A PC user cannot delete
the object through a System i® Access
interface. A System
i user
with a fixed function workstation cannot delete the object either, even if
the System
i user has *ALLOBJ
special authority. Before the object can be deleted, an authorized user must
use a PC function to reset the read-only value to off. Similarly, a PC user
might not have sufficient IBM i authority
to change the PC-relevant security attributes of an object.
UNIX-type
applications that run on
IBM i use
UNIX-like application programming interfaces (APIs) to access data in the
root file system. With UNIX-like APIs, applications can recognize and maintain
the following security information:
- Object owner
- Group owner (System
i primary
group authority)
- Read (files)
- Write (change contents)
- Execute (run programs or search directories)
- S_ISVTX mode bit (restricted rename and unlink attribute)
The system maps these data authorities to existing
System
i object
and data authorities:
- Read (*R) = *OBJOPR and *READ
- Write (*W) = *OBJOPR, *ADD, *UPD, *DLT
- Execute (*X) = *OBJOPR and *EXECUTE
The concepts for other object authorities (*OBJMGT, *OBJEXIST, *OBJALTER,
and *OBJREF) do not exist in a UNIX-type environment.
However, these
object authorities do exist for all of the objects in the root file system.
When you create an object using a UNIX-like API, that object inherits these
authorities from the parent directory, resulting in the following situations:
- The new object’s owner has the same object authority as the parent directory’s
owner.
- The new object’s primary group has the same object authority as the parent
directory’s primary group.
- The new object’s public has the same object authority as the parent directory’s
public.
The new object’s data authority for owner, primary group, and public
are specified on the API with the mode parameter. When all of the object authorities
are set on, you get the authority behavior that you expect in a UNIX-type
environment. It is best to leave them set on, unless you do not want the POSIX-like
behavior.
When you run applications that use UNIX-like APIs, the system
enforces all object authorities, whether they are visible to UNIX-type applications.
For example, the system will enforce the authority of authorization lists
even though the concept of authorization lists does not exist in UNIX-type
operating systems.
When you have a mixed-application environment, you
need to ensure that you do not make authority changes in one environment that
will break your applications in another environment.