File Permissions determine what a user is allowed to do with that file. Since almost everything (including peripherals, etc.) manifests itself as a file under Linux, these permissions therefore also act on the use of those devices, etc.
The permission bits (9 in total) consist of a ReadBit, a WriteBit and an ExecuteBit for the file owner; read, write and execute for the group and read, write, execute for everyone else. In table form, it looks like this:
owner group others
r w x r w x r w x
The value of the various bits is as follows:
4 = read
2= write
1 = execute
So a combination of the numbers gives a certain amount of permissions. Thus, 777 is rights for everything and everyone.
When a user wants to do something with a file, the kernel first checks whether the user is the owner of the file; if so, the kernel gets the effective permissions from the owner rwx field. If the user is not the owner, the kernel checks whether the user is in the user group associated with the file, in which case the group rwx bits are used; otherwise the rwx bits for the others.
If the ReadBit is set in the selected field, the user is given permission to read the file; if the WriteBit is set the user is allowed to write to the file. For a Directory, the ReadBit means that the file list may be queried and the WriteBit means that the user may add and remove files from the directory.
For regular files, the ExecuteBit indicates that the file may be executed as a program. For scripts, this means that the interpreter specified in the script (see SheBang) is started that must read the file, so it is essential to also set the ReadBit in that case; this is not necessary for binaries.
For a directory, the ExecuteBit indicates whether files in the directory can be accessed. If only the ReadBit of the directory is set but the ExecuteBit is not, you can query the file names in the directory, but you cannot read or write the associated files. If the ExecuteBit is set but the ReadBit is not, you can use a file if you are able to guess the correct name.
In addition to the above-mentioned “normal” rights, a Unix file system has a number of special rights:
The sticky bit
The guid bit
The suid bit
The sticky bit ensures that only the owner can delete a file. You often find it on publication boards or in the /tmp directory.
You can set the sticky bit octal by putting 1 in front of the 3 other digits.
bilbo@bilbo:~$ ls -l example
-rw-r–r– 1 bilbo users 0 Jul 2 17:59 example
bilbo@bilbo:~$ chmod 1655 example
bilbo@bilbo:~$ ls -l example
-rw-r-xr-t 1 bilbo users 0 Jul 2 17:59 example*
bilbo@bilbo:~$
As you can see, the sticky bit is shown by a “t” (or “T” if the file is not executable) in place of the other execute bit.
You can also use “+t” with a chmod.
In folders where users who have different main groups go, you can expect problems with file ownership. New files and files that are modified are given group ownership by the main group of the user who creates or modifies the file. In a so-called group folder – where, for example, files from the group administration are located – the group ownership must remain on the group administration.
To achieve this, the GUID bit. Octally you can set it with the number “2”
root@bilbo:/home/bilbo# chmod 2655 example
root@bilbo:/home/bilbo# ls -l example
-rw-r-sr-x 1 bilbo wheel 0 Jul 2 17:59 example*
root@bilbo:/home/bilbo#
As you can see, the GUID bit is represented by an “s” (or an S if the file is not executable) or the location of the group execute bit.
You can also use “g+s” with chmod.
The latter is also a dangerous one. Namely the SUID bit. This bit ensures that the file – if it is executable – is executed as if it were being executed by the owner.
Octally you can set the SUID bit with the number “4”
root@bilbo:/home/bilbo# ls -l example
-rw-r-xr-x 1 bilbo wheel 0 Jul 2 17:59 example*
root@bilbo:/home/bilbo# chmod 4755 example
root@bilbo:/home/bilbo# ls -l example
-rwsr-xr-x 1 bilbo wheel 0 Jul 2 17:59 example*
root@bilbo:/home/bilbo#
As you can see, the SUID bit is represented by an “s” (or an “S” if the file is not executable by the owner) in place of the owner’s executable bit.
You can also use “u+s” with chmod.
A well-known example of a SUID program is passwd. This is the program that you can use as a normal user to change your password. However, as a normal user you are not allowed to modify /etc/shadow or /etc/passwd. For this reason, passwd is run as if it were run by root, the owner of passwd.
root@bilbo:/home/bilbo# ls -l which passwd
-rws–x–x 1 root bin 33924 Mar 10 03:22 /usr/bin/passwd*
root@bilbo:/home/bilbo#
SUID becomes dangerous if the bit is set on files where this is not intended. Take for example vi….. if that executable were SUID….. then anyone could edit files as if they were root.
