Fedora Linux

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.

4.8.1.7. Changing file ownership

The superuser can change the ownership of a file using the chown command:

# chown accountfile barbara

This is useful when moving files between user accounts (for example, when an employee has left a company).

4.8.2. How Does It Work?

A file's user, group, and mode information is stored in a file's inode a 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 (2³²-1). However, some older applications still use 16-bit GID and UID values, so it's best to use IDs under 65,532 (2¹⁶-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...

4.8.3.1. ...viewing file permissions and ownership in the icon view of Nautilus?

You can configure the icon view of Nautilus by selecting Edit>Preferences 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 View>Zoom In and View>Zoom Out) will adjust the amount of information displayed.

This feature is not available in Konqueror.

4.8.3.2. ...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.

4.8.3.3. ...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.

4.8.3.4. ...changing a file's owner and group at the same time?

The chown command permits you to specify a group after the username, separated by a colon. To make /tmp/input owned by the user barbara and the group smilies , use:

# chown barbara:smilies /tmp/input

4.8.4. Where Can I Find More Information?

? The manpages for chmod , chown , chgrp , newgrp , id , ulimit , umask , and groups