From Mandriva Community Wiki
The Ten-Character Permission System
By way of example, let's look at the long form directory listing from a couple of entries in the /etc directory of the Mandriva Linux file system:
The first example is a directory (/etc/sysconfig). We know this because the first character in the ten-character string at the beginning of the listing is a "d". We know the second file is a regular file because the first character in the ten-character string is a "-" (dash). We can also see that the owner (root) of the second file (sysctl.conf) has read and write permissions, but members of the "root" group and all others have only read permission. Here's how the system works:
As mentioned above, the first bit does nothing more than indicate what type of file this is. The user doesn't set this bit, it is set automatically by the file system. We call this the "Type" bit. This bit can hold one of 7 settings:
- d = directory
- l = symbolic link
- s = socket
- p = named pipe
- - = regular file
- c = character (unbuffered) device file, special
- b = block (buffered) device file, special
Permissions themselves are defined for "Users", "Groups", and "Others". The user is the owner of the file (root in the example above). Each user belongs to at least one group like the root group in the example above. There are others who may be able to access the file without being the owner of the file or a member of the file's group.
User: The username of the person who owns the file. By default, the user who creates the file will become its owner.
Group: The usergroup that owns the file. All users who belong to the group that owns the file will have the same access permissions to the file. This is useful if, for example, you have a project that requires a bunch of different users to be able to access certain files, while others can't. In that case, you'll add all the users into the same group, make sure the required files are owned by that group, and set the file's group permissions accordingly.
Other: A user who isn't the owner of the file and doesn't belong in the same group the file does. In other words, if you set a permission for the "other" category, it will affect everyone else by default. For this reason, people often talk about setting the "world" permission bit when they mean setting the permissions for "other."
Read Write Execute
Each of these three entities may have permission to read from, write to, or even execute files. The remaining nine characters can be set to provide permission for users, groups, and others to access the files at various levels. There are 5 possible characters in the permission fields. They are:
- r = read - This is only found in the read field.
- w = write - This is only found in the write field.
- x = execute - This is only found in the execute field.
- s = setuid - This is only found in the execute field.
- If there is a "-" in a particular location, there is no permission. This may be found in any field whether read, write, or execute field.
Read permission. On a regular file, the read permission bit means the file can be opened and read. On a directory, the read permission means you can list the contents of the directory.
Write permission. On a regular file, this means you can modify the file, aka write new data to the file. In the case of a directory, the write permission means you can add, remove, and rename files in the directory. This means that if a file has the write permission bit, you are allowed to modify the file's contents, but not rename or delete that file. You're allowed to rename or delete the file only if the permissions of the file's directory allow you to do so.
Execute permission. In the case of a regular file, this means you can execute the file as a program or a shell script. On a directory, the execute permission (also called the "search bit") allows you to access files in the directory and enter that directory, with the cd command, for example. Note however, that although the execute bit lets you enter the directory, you're not allowed to list its contents, unless you also have the read permissions to that directory.
Setuid. When the execute bit for the owner is set to "s" the set user ID bit is set. This causes any persons or processes that run the file to have access to system resources as though they are the owner of the file. When the execute bit for the group is set to "s", the set group ID bit is set and the user running the program is given access based on access permission for the group the file belongs to. There is more information about the setuid bit below in Advanced GUI Options
So, the ten bits in question are laid out like this in the long form file listing we looked at above:
|--User Permissions--| |-- Group Permissions--| |-- Other Permissions--| 1 2 3 4 5 6 7 8 9 10 Type Read Write Execute Read Write Execute Read Write Execute d r w e r w e r w e
In the first file, actually a directory:
Root can read, write and execute (rwx), members of the root group can read and execute (r-x), and others can also read and execute from the directory (r-x). Everyone can CD into and list the directory contents, but only root can create or modify files.
The second file:
Allows the owner (root) to read and write, while members of the root group and others may only read the file. It should be noted that a .conf file is only a plain text configuration file and is never executable, hence no one has execute permissions on the file in this example.
Files are created with default permissions set according to rules in the file system, but what if those permissions are not quite right? Keeping a multi-user system secure and functional will ultimately require that an administrator manipulate permissions on files and directories. Not only is it necessary to prevent users from changing files that the system depends on for stable functioning, but some users will need access to view or change some files while other files remain totally beyond their reach. This is what file system permissions are all about.
Files in a Linux file system are explicitly owned by two entities -- a user and a group. As stated earlier, each user belongs to at least one group. The ability to belong to more than one group gives the file system's permission scheme much more flexibility as you will see below. In our example files, we can see that the sysctl.conf file is owned by the root user and the root group.
Other files of course, may have other ownership. For example:
-rwxr-xr-x 1 guest guest 5411288 2004-02-14 10:31 Pink - God is a DJ-try this-CLEAN.mp3 -rwxr-x--- 1 adams adams 1826786 2005-10-30 15:26 Wacom_G4Manual.pdf
The first file is owned by the user named "guest" and members of the "guest" group. The user named "guest" has full permission to read write and execute the file while the members of the "guest" group and others may only read and execute it. Given that this is an mp3 audio file, execute permission is not critical and the risk of malice is low. Note, only users with write permission can delete the file.
The second file is a PDF that the owner "adams" can read, write, and execute. Members of the "adams" group can read and execute the file, but others can't access it at all. Suppose we wanted to make this PDF available to more users. We could, for example change the ownership of the file to allow members of the "users" group to access the file.
To do this we would use the chown command.
That would look something like this:
This command would have to be executed by a user with permissions equal to or greater than "adams". Once done, the long form listing for the file would look like this:
-rwxr-x--- 1 adams users 1826786 2005-10-30 15:26 Wacom_G4Manual.pdf
Now, members of the "users" group can read and execute the file. In some cases it might be useful to create groups to provide a specific level of access to some files for a group of users working on a specific task. For example, a group called "news" could be created for the members of a team working on a Wiki page. Then a directory and set of files specific to that Wiki page project could be assigned ownership including the "news" group and sufficient access could be granted to the files for that group.
There are two methods or modes that an administrator may use to directly alter file permissions. This section will examine Symbolic Mode and Numeric Mode as they relate to tuning file permissions in a Linux system.
A more direct way of affecting permissions is with the chmod command. This command allows users to set the nine bits that define permissions for the three entities. For example, lets look at changing the permissions for our mp3 file above.
-rwxr-xr-x 1 guest guest 5411288 2004-02-14 10:31 Pink - God is a DJ-try this-CLEAN.mp3
If we wanted to disallow anyone but the "guest" user and members of the "guest" group from listening to this audio file we could change it in one of two ways with the chmod command. In symbolic mode, since user and group "guest" have permission to read and write, we just need to remove permissions for Others.
(Note that the spaces in the filename require that the filename be enclosed in quotes.)
If we needed to change permissions for Owner (aka User) and Group, we would simply execute:
Now the file permissions look like this:
-rwxr-x--- 1 guest guest 5411288 2004-02-14 10:31 Pink - God is a DJ-try this-CLEAN.mp3
The symbols in this context of the chmod break down like this:
|What to do?|
|+||add this permission|
|-||remove this permission|
|=||set exactly this permission|
While the Symbolic Mode of file permissions is somewhat easier for some users to remember, the Numeric Mode may be easier for others. This method uses a three-digit octal number to represent permissions.
- 4 = read (r)
- 2 = write (w)
- 1 = execute (x)
- 0 = no permission (-)
To get the permission bits you want, you add up the numbers accordingly. For example, the rwx permissions would be 4+2+1=7, rx would be 4+1=5, and rw would be 4+2=6. Because you set separate permissions for the owner, group, and others, you'll need a three-digit number representing the permissions of all these groups.
For example, the mp3 file we have been using would have the permissions 755.
-rwxr-xr-x 1 guest guest 5411288 2004-02-14 10:31 Pink - God is a DJ-try this-CLEAN.mp3
Under 755 permissions, the user would have read+write+execute (4+2+1=7) permission, while the group and others would have read+execute (4+1=5) permission. So "rwxr-xr-x" = (421|401|401) = 755
To use Numerical Mode to change permissions on our first file to deny read, write, and execute permissions to everyone but the owner, the chown command would look like this:
which would result in:
-rwx------ 1 guest guest 5411288 2004-02-14 10:31 Pink - God is a DJ-try this-CLEAN.mp3
Doing the math results in a list of permissions that looks like this:
That's all pretty handy information, but what if you've got a whole directory full of files you need changes to ownership or permissions. According to the Man pages, these commands accept the "-R" switch to apply changes recursively. That is, all files and/or directories under the working directory on which the command is executed will be changed.
Will change the owner of all files and directories under /home/ftp-shared to user = frodo and group = frodo.
The GUI Way
It is also possible to set permissions via a graphical user interface (GUI). Typically, this means using a file manager like Konqueror or in this case, Dolphin. Remember: in order to change permissions you must have authority at least equal to the owner of the file, therefore, you may need to run your file manager as root. This works well for one file at a time, but efforts to change the permissions of file recursively (that is, whole directories and subdirectories of files) have been described as "inconsistent." For changing more than one file at a time, the command line interface may be much more efficient.
To set file permissions in a GUI:
- Open the GUI
- Navigate to the file you wish to change
- Right-click on the file in question
- Click on the "Properties" menu item or press Alt+Return
- Click on the "Permissions" tab
- Use the pick lists to set read/write permissions for the three entities
- Use the checkbox to determine whether the file is executable or not
Follow steps 1 - 5 above and click on the "Advanced Permissions" button. From here you can use the checkboxes to set individual read/write/execute permissions for the three entities. You can also set special permissions for Set UID, Set Gid, and the "Sticky bit".
The Setuid has been explained above and Setgid works in a very similar manner. When any user runs an executable file that has either of these bits set, the system gives the user the identity of the owner (and or group) of the executable. This means that the user's process changes its identity.
For example, the command used to change a login's password, passwd, is set-UID to root because the new password must be written to the /etc/shadow file, and that file is writable only by root.
While the set-UID and set-GID mechanisms provide a convenient way to allow ordinary users to run a command that needs to perform a privileged operation, usage does pose some security risk, primarily for files with the set-UID bit set.
For example, if a user were somehow able to obtain a copy of the shell and change it to be set-UID to root, then the user could become superuser simply by running the modified shell.
The "Sticky" bit is currently deprecated and therefore ignored by the Linux kernel. Once upon a time, the "Sticky" bit instructed the operating system to hoard an executable in swap space after the process exited. Subsequent executions of the program could be much faster. Unfortunately, it wound up causing problems during certain operations like patching the application that was "sticky". So set the bit, don't set the bit -- Mandriva takes no notice.
As a multi-user file system, Linux uses a system of file permission to allow administrators to tune access so that users can create, read, edit, and delete files in order to do what they need to do. It also allows administrators to deny access to files that users should not have access to for whatever reason. This permission may be altered in one of several ways for individual files or whole directories. This Wiki page provides an introduction to this system of file permission. Further resources are listed below, and as always, read the man pages (man chmod).