Every file is created with an access mode. Each access mode grants read, write, or execute permission to users, the user's group, and all other users.
The access bits on a newly created file are a result of the reverse of the umask bits ANDed with the file-creation mode bits set by the creating process. When a new file is created by a process, the operating system performs the following actions:
For example, if an existing file has the 027 permissions bits set, the user is not allowed any permissions. Write permission is granted to the group. Read, write, and execute access is set for all others. The umask value of the 027 permissions modes would be 750 (the opposite of the original permissions). When 750 is ANDed with 666 (the file creation mode bits set by the system call that created the file), the actual permissions for the file are 640. Another representation of this example is:
027 = _ _ _ _ W _ R W X Existing file access mode
750 = R W X R _ X _ _ _ Reverse (umask) of original
permissions
666 = R W _ R W _ R W _ File creation access mode
ANDED TO
750 = R W X R _ X _ _ _ The umask value
640 = R W _ R _ _ _ _ _ Resulting file access mode
The umask subroutine sets and gets the value of the file creation mask. The chmod and fchmod subroutines change file access permissions.
The access subroutine investigates and reports on the accessibility mode of the file named in the Pathname parameter. This subroutine uses the real user ID and the real group ID instead of the effective user and group ID. Using the real user and group IDs allows programs with the set-user-ID and set-group-ID access modes to limit access only to users with proper authorization.
Consider the following example:
$ ls -l total 0 -r-s--x--x 1 root system 8290 Jun 09 17:07 special -rw------- 1 root system 1833 Jun 09 17:07 secrets $ cat secrets cat: cannot open secrets
In this example, the user does not have access to the file secrets . However, when the program special is run and the access mode for the program is set-uID root , the program can access the file. The program must use the access subroutine to prevent subversion of system security.
The access subroutine must be used by any set-uID or set-gID program to forestall this type of intrusion.
The chown subroutine resets the ownership field of the i-node for the file and clears the previous owner. The new information is written to the i-node and the process finishes. The chmod subroutine works in similar fashion, but the permission mode flags are changed instead of the file ownership.
Changing file ownership and access modes are actions that affect the i-node, not the data of the file. The owner of the process must have root user authority or own the file to make these changes.
Files, Directories, and File Systems for Programmers gives an overview and orientation to these topics.
The access, accessx, or faccessx subroutine, the chown, fchown, chownx, or fchownx subroutine, and the chmod or fchmod subroutine.