4.8. Control Access to Files
All Linux and Unix systems use file permissions or modes to control access to files. Fedora extends this with the user-private-group scheme, which simplifies the configuration of permissions for collaboration.
4.8.1. How Do I Do That?
There are three basic file permissions:
Remember the order: r w x.
Each of these three permissions is granted or denied to users in three different communities:
The order is significant here, too; you'll want to memorize it: u g o.
This gives a total of nine permissions for each file and directory:
There are also three special file permissions, as outlined in Table 4-13.
The SUID and SGID permissions provide critical abilities. For example, /etc/passwd and /etc/shadow are only writable by root, but normal users need to be able to change their passwords. The program /usr/bin/passwd is owned by root and has the SUID permission enabled, so it runs with root privilegeregardless of who executes itand is therefore able to change /etc/shadow.
188.8.131.52. Viewing the current user, group, and mode from the command line
$ ls -l /etc/aliases.db -rw-r----- 1 root smmsp 12288 Oct 6 19:31 aliases.db
The first field displayed is -rw-r-----. The first character is reserved for file type information, and the rest of that field contains the file's mode: rw-r-----.
This mode breaks down into three sets of three characters, representing the permissions granted to each of the three communities:
Notice that these communities are displayed in the u g o order mentioned earlier.
The three characters displayed for each of these communities represent read, write, and execute permission; if the permission is denied, a dash is shown, but if the permission is granted, the letter r, w, or x is shown, in that order (r w x).
In order to correctly interpret the permission, we need to know who the user and group are. The ls -l output shows this information in fields 3 and 4; in this case, the user is root and the group is smmsp.
Putting this all together, we know that:
184.108.40.206. Viewing the current user, group, and mode graphically
GNOME's Nautilus file manager normally displays files and directories as icons. To change the display to a list resembling the output of ls -l, select the menu option ViewView as List. The default display shows the file name, size, type, and date modified.
You can add the permissions, owner, and group to the display by selecting EditPreferences, which presents the File Management Preferences window shown in Figure 4-11. Click on the List Columns tab, and then click on the checkboxes for permissions, owner, and group to include them on the display. You can also use the Move Up and Move Down buttons to change the displayed order of the fields. Click Close when the display is configured to your liking.
Figure 4-11. Nautilus File Management Preferences window
KDE's Konqueror application provides a similar display when you select ViewView ModeDetailed List View.
220.127.116.11. Changing permissions graphically
Right-clicking on a file in Nautilus or Konqueror will bring up the file Properties window shown in Figure 4-12. The Permissions tab within that window contains checkboxes for each of the three permissions in each of the three communitiesnine checkboxes total, plus three for the special permissions (to view the checkboxes in Konqueror, use the Advanced Permissions button).
Figure 4-12. Nautilus File Properties window
18.104.22.168. Changing permissions from the command line
The chmod (change-mode) command is used to change permissions from a shell prompt. The permissions can be specified using either of two different syntaxes: relative symbolic notation or octal notation.
Relative symbolic notation uses any combination of the three community letters (u, g, or o) or the letter a to indicate all three communities; an operation symbol, which is + to add a permission and - to remove it, or = to exactly set a permission; and finally, one or more permission letters (r, w, or x). Table 4-14 shows some examples of relative symbolic notation; note that multiple operations can be specified using commas as separators (no spaces).
Therefore, the octal permission 764 represents read/write/execute for the user (4+2+1=7), read/write for the group (4+2=6), and read for others (4): rwxrw-r--.
When using octal notation, special permissions are given as a fourth digit placed in front of the others; the value of this fourth digit is the sum of 4 for SUID, 2 for SGID, and 1 for Sticky. Octal permission 2770 represents rwxrws---.
To change a permission with chmod, specify the permission as the first argument and one or more filenames as the remaining arguments:
$ ls -l oreilly -rw-rw-r-- 1 chris chris 40 Oct 12 17:18 oreilly $ chmod g-w,o= oreilly $ ls -l oreilly -rw-r----- 1 chris chris 40 Oct 12 17:18 oreilly $ chmod 764 oreilly $ ls -l oreilly -rwxrw-r-- 1 chris chris 40 Oct 12 17:18 oreilly
$ chmod -R o-w ~
22.214.171.124. Using group permissions
Users can belong to more than one group, which enables documents to be shared according to group roles.
Previously, we used Richard in group examples; he's a member of the groups richard, it, toronto, acmeproposal, christmas, soccer, and audit. Richard's primary group is richard, as that is the group listed in his entry in /etc/passwd. When Richard logs in, the shell starts with its group identity set to the primary group, so any new files or directories created have richard as the group owner.
richard$ id uid=503(richard) gid=503(richard) groups=503(richard),504(audit),505(soccer), 506(toronto),511(acmeproposal),512(christmas),608(it) richard$ newgrp audit richard$ id uid=503(richard) gid=504(audit) groups=503(richard),504(audit),505(soccer), 506(toronto),511(acmeproposal),512(christmas),608(it)
The current group identity (also called real group ID) affects only the creation of files and directories; existing files and directories keep their existing group, and a user can access files accessible to any group to which she belongs.
In this case, Richard can access any file that is readable by, say, the acmeproposal group, even when his current real group ID is audit. However, any files he creates will be owned by the group audit and won't be accessible to the acmeproposal group.
$ ls -l report.txt -rw-r--r-- 1 richard richard 3078 Oct 12 19:35 report.txt $ chgrp audit report.txt $ ls -l report.txt -rw-r--r-- 1 richard audit 3078 Oct 12 19:35 report.txt
A normal user can set the group ownership only to one of the groups to which he belongs, and can change the group ownership only of files that he owns. The root user can set the group ownership of any file to any group. Like chmod, chgrp accepts the -R (recursive) option.
Richard could create a directory named game_scores in his home directory, change the group ownership to soccer, and change the permission to rwxrws---:
richard$ mkdir game_scores richard$ chgrp soccer game_scores richard$ chmod u=rwx,g=rwxs,o= game_scores richard$ ls -ld game_scores drwxrws--- 2 richard soccer 4096 Oct 12 19:46 game_scores
Everyone in the soccer group can access that directory. Because the SGID permission is set, any file created in that directory is automatically owned by the group soccer and can be accessed by other group membersexactly what is needed for collaboration within a group. The SGID permission is automatically applied to any directory created within games_scores, too.
126.96.36.199. Default permissions
When a Fedora program asks the Linux kernel to create a new file or directory, that program requests a default set of permissions. OpenOffice.org, for example, requests mode 0666 (rw-rw-rw-) on new files, because it knows that they aren't executable; the C compiler, on the other hand, requests 0777 (rwxrwxrwx) because the output of the C compiler should be an executable program.
This requested permission is limited by the current umask, which is an octal value representing the permissions that should not be granted to new files. If you want to prohibit anyone in your group from writing to or executing your files, and prevent others from doing anything at all with your files, the permissions that you want to restrict are ----wxrwx. In octal, that translates to 037.
You can set the umask with the shell command of the same name:
$ umask 037
$ umask 0037
This value is inherited by child processes, including all applications started by the shell.
The actual permissions set on a new file will be the permissions requested by the application after the permissions restricted by the umask are removed:
OpenOffice.org requested permission: rw-rw-rw- Permissions restricted by umask: ----wxrwx Permission applied to a new file: rw-r-----
The normal umask on Fedora systems is 002, which gives full read and write permission to everyone in your group. This works well in group-collaboration directories that have SGID permission set; other group members will be able to edit the files you have created, and vice versa. The beauty of the Fedora user-private-group system is that when you're not in a collaboration directory, new files default to ownership by your private group. This makes group permissions moot, since they apply only to you and are therefore effectively the same as the user permissions.
188.8.131.52. Changing file ownership
# chown accountfile barbara
4.8.2. How Does It Work?
A file's user, group, and mode information is stored in a file's inodea small disk-based data structure containing vital information about a file. The user and group are stored as 32-bit numbers, which means that the maximum GID and UID are both 4,294,967,295 (232 1). However, some older applications still use 16-bit GID and UID values, so it's best to use IDs under 65,532 (216 4)plenty for most systems. IDs under 500 are reserved for system services; this is really just a convention adopted to avoid conflicts, since there is nothing special about user IDs with low numbers.
There is something special about user ID 0, though: it's reserved for the superuser, root. It is possible to create multiple accounts with the same ID, and this is sometimes used to create a second superuser account with a different password from the root account.
Each process also has a data structure that stores its real UID and GID, the effective UID and GID (which are different from the real IDs when a SUID or SGID program is running), and the umask. This data is copied to child processes automatically, but if the child process is a bash or csh shell, the umask value is reset by the shell startup scripts (/etc/bashrc or /etc/csh.cshrc).
4.8.3. What About...
184.108.40.206. ...viewing file permissions and ownership in the icon view of Nautilus?
You can configure the icon view of Nautilus by selecting EditPreferences and going to the Display tab. Up to three fields can be configured, in addition to the filename; by default, the first field is blank, the second field is the file size, and the third field is the date modified. Normally, only the first field is shown beneath each icon, but zooming in and out (using the menu options ViewZoom In and ViewZoom Out) will adjust the amount of information displayed.
This feature is not available in Konqueror.
220.127.116.11. ...changing the group of a file graphically?
The permissions tab of the file properties window in both Nautilus (Figure 4-12) and Konqueror has a drop-down menu that permits you to change the group ownership if you are a member of multiple groups and you own the file.
18.104.22.168. ...deleting someone else's file in /tmp?
/tmp is a special directory used to store temporary files ( /var/tmp is another). Since this directory is shared among all users, the sticky bit has been set to prevent users from deleting one other's files.
22.214.171.124. ...changing a file's owner and group at the same time?
# chown barbara:smilies /tmp/input
4.8.4. Where Can I Find More Information?