Because the Unix system was designed as a programming environment for groups of researchers, the file system's access control reflects this.
As mentioned before, Unix recognized three types of individuals who may want to access a file. The user (or owner of the file), a member of a group associated with a file, and all others. You, as the the owner (user) of a file, control access by individuals in each of these categories.
Read permission allows the specified individual to view or copy the contents of the designated file.
Write permission grants the right to change the contents of a file.
And Execute permission allows the individual the ability to request that the specified program be run. The file must contain valid instructions, whether it is binary or a shell scripts. Also, it may be necessary to specify the path to the file if the directory listing the file of interest is not listed in the PATH shell variable.
Permission effects on directories differ from their effects on other file types.
Read permission on a directory allows an individual to see the list of filenames stored in a directory. It is also necessary when using redirection because the command interpreter must confirm the filename when setting up redirection and possible filename expansion before execution of command line.
However, directory read permission alone are not sufficient to allow access to the files listed. Each file's access is controlled by a collection of metadata known as an inode. The inode is referenced to locate the file's data, to check its ownership and access permissions, and other information about the file. The location or index of the file's inode is stored in the directory listing. However, the directory will only provide the index of the inode if the directory's execute permissions are set. It is not possible to access a file from a directory listing if a directory has read but not execute permissions. But, it is possible to access a file listed in a directory that is not readable as long as you know the exact name of the file and the directory has execute permissions.
Write permission on a directory allows a user to enter a new filename into the directory list as long as the execute permission on directory is also set.
As mentioned above, execute permissions allow the operating system to identify the inode of a file of interest and, through the inode, the file's data. Any action, other than simply listing the directory's contents, works only if the execute permissions are set.
SUID (setuid)
When a file is created, its ownership or user id is set to the id of the individual creating it and is referred to as the real id. However, when the program stored as a file is executed, the running program is assigned a second owner id called the effective id, which is the id of the individual running it. This is a security feature that prevents the individual running the program from masquerading as the real owner of the running program and gaining access to the real owner's files through the running program.
However, there are times when that is exactly what the creator or real owner of the program intended. An example of this is accessing the password file /etc/passwd. This file is owned by root, is publicly readable, but is writable only by root.
However, for you to change your own password, you must have the ability to change /etc/passwd. You may do this with the command passwd, an executable file owned by root. In order to accomplish this switch in "effective" ownership of the passwd command, the suid (set user id) permission or bit must be set on the program file.
When passwd command is executed, the suid bit instructs the operating system to allow the passwd command's effective id to remain "root" for the duration of the command's execution. Note that there is a real security issue here. It is important that the file being run performs exactly the intended and only the intended function it was designed for.
In general, the suid bit should not be set.
SGID
Similar to the suid except that it applies to the group category. When you were recognized as a valid user on the system, you were assigned a unique user id (uid). You were also assigned to a group and given a group id (gid). Every file you create is tagged with these two ids and you can control access permissions for yourself, other members of the group, and independently, everyone else.
Although you belong to a default group, it is possible for the system administrator create additional groups and assign you as a member of any or all of those.
Note that the categories of user, group, and other are mutually exclusive, so if you turn off read access for yourself as user or owner, you cannot access the file, even if your group permissions allow members of your group access.
The sgid has the same effect as suid but with group permissions. The sgid bit has a special feature when applied to a directory file. In most Unix systems, when a file is created, its group association is assigned to match the default group association of the individual creating the file even if the group id of the directory the file is created in belongs to a different group. By setting the sgid bit on a directory, you are instructing the operating system to use the group id of the directory the file is being created in as the group id of the file. This is useful when the directory has been set up to share files among a group of users different from the default group of the owner of the directory.
Note that Berkeley Unix systems normally functions as if the sgid is set by default.
The third special bit or permission of interest is the sticky bit. Originally designed to tell the operating system to keep a program in memory when terminated. This bit was set on programs that were run often and it instructed the operating system to leave the flagged program in memory even if it was not running at the moment. Because loading program from storage often took longer than executing it, this provided significant performance improvement.
On newer systems, this often happens anyways and does not need to be requested.
The sticky bit has evolved to perform another function when set on a directory file. When set, the sticky bit protects programs created in a directory by someone other than the owner of the directory from being removed by anyone but the directory owner, the person creating the file, or the system administrator.
Suppose that a group of developers are using a directory owned by the head developer to create a series of files for a project. All users have been given permission write to the directory (along with read and execute permissions). This allows each user to create a file in this directory which would be owned by her/him and he/she could control access permission to that file. However, because all users have the same access permission to the directory itself, it would be possible for one user to delete another user's file and replace with their file under the same name.
Enter the sticky bit. By setting the sticky bit on the directory, the owner of the directory is indicating that the system should prevent other users who have the permission to create/delete files in the directory from deleting any files that are not their own.