Because the Unix system was designed as a programming environment for groups of researchers, the file system's access control reflects this.
There are three properties that combine to determine exactly how a file is accessed. These are user access, file mode, and file type.
Unix recognized three types of individuals who may want to access a file, the user (or owner of the file), a member of the group associated with the file, and all others. The owner of a file controls the "user access" by individuals in each of these categories.
Unix provides the file mode to control the type of access. There are several, the most common being read permission, write permission, or execute permission. The additional file modes serve special purposes and will be covered later.
User access and file mode are separate properties but are most commonly modified by the chmod command and can be combined in a number of ways.
Unix recognizes several file types, the most common file types are regular files, symbolic links, and directories. Generally, these are set automaticly by the commands creating the file. The main exception to this is the symbolic link which users are free to create when needed.
We will look at the other file types when needed.
When a file is created, Unix needs a mechanism by which it can track and control the file. Unix does this with a hierarchical directory system and a structure called an inode.
Each file created receives a single inode and the Id of the inode and a name is entered into one of the directories in the directory system.
Users may enter additional names for certain types of file in the directory structure with the approrpiate command. Each of these names will refer to the assigned inode Id.
An inode contains several pieces of information, including the user access settings, the file mode settings, the file type, the number of names assigned to the file, and the locations on the storage device where the blocks of the file are stored.
The 3 user access properties are user(owner), group, other.
User ID
When a user account is created on a Unix system, it is assigned a unique ID called the uid. This ID is used to label any file created by that user and marks it as her/his. This in turn, in most cases, allows the user complete control over that file.
Note that if a user has accounts on different systems, her/his user ID may be different even if her/his login ID is the same. Howover, many organizations have policies/mechanisms to use a single uid for single person whereever possible for security reasons.
Group ID
Group IDs are more flexible. A user can belong to several groups and and groups, by their nature, can contain many users.
A group can only be created by the system admin. and only he/she can assign a user to a group.
When a user account is created, it is associated with a single default group. Any file created by the user is normally assigned the default group ID. And a file can only be assigned a single group ID(gid).
A user may change a file's group ID to any group he/she is a member of with either the chown or chgrp.
Historically, the group IDs are kept in /etc/group and are publicly readable. Modern systems may augment this with an enhanced database following the LDAP protocol.
Read permission grants the right 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 grants the right to execute the program. 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 meta-data known as an inode. The inode is referenced to locate the file's data, to check its ownership and access permissions, and to access other information about the file.
A file's inode ID is stored in the directory listing. The directory will only provide the index of the inode if the directory's execute permissions are set. Read permission is not sufficient to provide the inode ID. But, it is possible to access a file listed in a directory that is not readable as long as the exact name of the file is specified 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)
A file that has its execute property set may be referred to as a command or program. The terms may be used interchangably in the following discussion.
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, if regular file marked as executable is run, 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.
A user can change their password with the passwd command. In order for this to work, the passwd program's SUID bit has been set. When passwd runs, it's real and effective ownership remain root's. This allows the passwd command to modify th e/etc/passwd file.
The passwd command has been carefully designed to make sure the user only modifies their own entry in the passwd file.
In general, the SUID bit should not be set. And when used, care should be taken in the design of the program being run.
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.