File permissions

UnixWare defines access-control and privilege mechanisms to allow for extended-security-controls that implement security policies different from those in UnixWare, but which avoid altering or overriding the defined semantics of any functions in UnixWare. Although quite simple, the access-control scheme has some unusual features. Each UnixWare user has a unique user-identification (user-id) number, as well as a shared group-identification (group-id) number. A file is tagged with the user-id and group-id of its owner, and a set of access-permission-bits when created by open, creat, mkdir, mknod and mkfifo (see open(2), creat(2), mkdir(2), mknod(2) and mkfifo(3C)). UnixWare file-access-control uses the access-permission-bits to specify independent read, write and execute permissions for the ``owner'' of the file, for any members of the owner's ``group'' and for any ``other'' users. For directories, execute permission means ``search'' permission. These access-permission-bits are changed by chmod, and are read by stat and fstat (see chmod(2), stat(2) and fstat on the stat(2) manual page).

When a process requests file-access-permission for read, write or execute/search, access is determined as follows:

1. If the effective-user-id of the process is a user with appropriate access-permissions (such as a privileged user).

   1. If read, write or directory search permission is requested, access is granted.

   2. If execute permission is requested, access is granted if execute permission is granted to at least one user by the file-permission-bits or by an alternate-access-control mechanism; otherwise, access is denied.

2. Otherwise:

   1. The read, write and execute/search access-permissions on a file are granted to a process if one or more of the following are true (see chmod(2)):

      • The appropriate access-permission-bit of the ``owner'' portion of the file-mode is set and the effective-user-id of the process matches the user-id of the owner of the file

      • The appropriate access-permission-bit of the ``group'' portion of the file-mode is set, the effective-group-id of the process matches the group-id of the file and the effective-user-id of the process fails to match the user-id of the owner of the file.

      • The appropriate access-permission-bit of the ``other'' portion of the file-mode is set, the effective-group-id of the process fails to match the group-id of the file and the effective-user-id of the process fails to match the user-id of the owner of the file.

      Otherwise, the corresponding access-permissions on a file are denied to the process.

   2. Access is granted if an alternate-access-control mechanism is not enabled and the requested access-permission-bit is set for the class to which the process belongs, or if an alternate-access-control mechanism is enabled and it allows the requested access; otherwise, access is denied.

Implementations may provide additional-file-access-control or alternate-file-access-control mechanisms, or both. An additional-access-control mechanism only further restricts the file-access-permissions defined by the file-permission-bits. An alternate-access-control mechanism shall:

1. specify file-permission-bits for the file-owner-class, file-group-class and file-other-class of the file, corresponding to the access-permissions, that stat and fstat return.

2. Be enabled only by explicit user action, on a per-file basis by the file-owner or a user with the appropriate-privilege.

3. Be disabled for a file after the file-permission-bits are changed for that file with chmod. The disabling of the alternate mechanism need not disable any additional mechanisms defined by an implementation.

UnixWare recognizes one particular user-id, the ``super-user'', as exempt from the usual constraints on file access; thus, for example, programs may be written to dump and reload the file system without unwanted interference from the protection system. A process is recognized as a super-user process and is granted special privileges if its effective-user-id is 0.