Changes to
Default Linux
Permissions

The SSCC will be implementing a new set of default Linux permissions. The result of these defaults will be to make new files created in private directories private, and new files created in public directories public. This will make managing project directories and sharing files with others much easier. This change will be implemented on Wednesday, January 16th.

This article will explain how this new permission scheme works, but the major goal of this change is to make it so most SSCC Members won't have to worry about the details of Linux permissions.

The new system will make four changes compared to our current system:

1. We will create a private group for each user containing only that user. New files will be associated with that private group by default.
2. All user home directories will be associated with the user's private group, and will be made readable and writable only by the user.
3. All project directories (and other shared directories) will be set so that new files created in them are automatically associated with that project's group.
4. The default permissions for new files (umask) will be set to allow the group to read and change the file.

Thus if a user creates a new file in her home directory or other private directory, it is associated with her private group. The group has permission to read and change the file, but since she's the only one in the group the file remains private.

If a user creates a new file in a project directory or other shared directory, the file is automatically associated with that project's group. The default permissions thus allow everyone in that group to read and change the file.

With the new system, who can read and change a file depends on where the file is located, which is similar to how Windows permissions work now. Users will still be free to set their own permissions. But we think this system makes it much more likely that the defaults will be what people want, so fewer people will have to make permission changes.

In order to make a private goup for each individual some of our current groups have been renamed. If a current group had the same name as a user (e.g. hauser) we renamed it by adding "grp" to the end. Thus the old hauser group has been renamed hausergrp so that we can make a new hauser group which will be the private group of user hauser.

Also note that any custom umask settings will be replaced with the new default.

Feel free to contact the consultant if you have questions or concerns about this change.

Examples:

Suppose user Jane Doe (jdoe) creates a new file in her home directory. Here is how the file would appear in a directory listing (ls -l):

-rw-rw---- 1 jdoe jdoe 0 Oct 10 11:42 newfile

Since jdoe is the only member of the jdoe group, she is the only one that can read or change the file even though the group has both "read" and "write" permissions.

Now suppose jdoe has a group she collaborates with called cookiedoe, and a project directory where they can share their recipes...er, files. Here is how that project directory would appear:

drwxrws--- 2 jdoe cookiedoe 4096 Oct 10 11:42 cookiedoe

Note the "s" in the permissions string. This means that "set Group ID" is on, meaning that new files created in this directory will belong to the cookiedoe group rather than the user's private group. When Jane creates a file in the project directory, here's how it will appear:

-rw-rw---- 1 jdoe cookiedoe 0 Oct 10 11:42 newfile

Now the fact that the file can be read and changed by the group actually matters. Everyone in the cookiedoe group will be able to read and change the file, which is usually the whole point of having a project directory. Of course if Jane wanted to set different permissions she could.