One of the most common problems that comes to the consultant is "I'm supposed to work on such-and-such file, but I can't!" Most often that's because as far as Linux is concerned the person was never given permission to work on the file. This article will talk about Linux permissions, and how to make sure that everyone who should can access a set of shared files and directories. This is particularly important for group leaders, who have to deal with these issues on a regular basis.
How the Consultant Can Help
As mentioned above, people often come to the consultant if they cannot access a file. The first thing the consultant will do is determine why this is the case. But assuming it is a permissions issue, SSCC staff must assume that the owner of the file intended to set permissions the way they did, and staff will only change them if the owner of the file specifically requests that we do so. To do anything else would invite security problems. The only exceptions are files stored in project directories. We will change permissions for files in a project directory at the request of the owner of the directory, even if they are not the owner of the particular file.
What we can do is identify who the owner of the file or group is, and what exactly must be done to allow you to work with a given file or directory. In some cases the owner can take care of it themselves; in some cases they will need help from the consultant--which we will be happy to provide at their request.
How Linux Permissions Work
Linux keeps track of permissions for each file or directory for three groups of people: the owner, the group, and others (everyone but the owner and the group). The owner is the person who created the file. Groups are sets of users who share files--they are created and modified by the Linux system administrator. Everyone has at least one group, a primary group, and can be added to others depending on what they need access to. For example, user kvelyvis has the primary group palloni, since user palloni is her advisor. However she also belongs to the sxnet, hospital, and prcensus groups. Each of these give her access to files relating to those projects. Each file has a group affiliation as well, which can be changed as needed.
There are three things people can be given permission to do: read, write, and execute. For files, read allows you to view or copy the file, but does not allow you to make changes. Write allows you to change or delete the file. Execute allows you to run the file as a program--this is rarely needed.
For directories, read allows you to get a listing of the directory. Write allows you to make new files in the directory. Execute allows you to make that directory your current working directory (e.g. you can cd to it). This affects any subdirectories as well: in order to go to a subdirectory you must have execute permissions for that subdirectory and all its parent directories.
Suppose you've just requested a new directory under /project, and you want to make certain other people can also use that directory. The first step is to send a request to the consultant that we create a new group consisting of you and those other people. Then you need to change the group affiliation of the directory to the new group, rather than your primary group (though if you tell us what group the directory should belong to when you request that we make the directory, we'll do this for you). Then you need to give group read, write, and execute permissions for that directory.
All three steps are necessary. If a person is not in the group, it doesn't help them that the file has the right group affiliations and group permissions. If the file does not belong to the group, it doesn't matter that the right people are in the group and the group permissions are set properly. If a file does not have group permissions set, it doesn't matter that it belongs to the right group and all the right people are in the group.
How to Set Linux Permissions
Now that you know what to do, let's talk about how to do it. Most of these steps are done in Linux. If you're not comfortable with the Linux file system and using cd to navigate around it, please see our SSCC Linux Handbook, or ask the consultant for help. On the other hand knowing cd and what to cd to is all the Linux you'll need to carry out these steps other than what is described here.
Defining a Group
Defining a group must be done by our Linux system administrator. If you need a new group, please send the consultant an email telling us the name of the group and who should be in it. Unless you tell us otherwise, you will be considered the owner of the group and any changes (adding or removing people) must come from you. If you need to add people to a group or remove them, please contact the consultant again and we will do it for you. If you need to be added to a group, please talk to the group's owner (the consultant can help you find out who that is) and have them send the request to the consultant.
Changing the Group Affiliation of a File or Directory
Changing the group affiliation of a file or directory can be done in Linux with the chgrp command. The syntax is simply
> chgrp groupname filename
where groupname is the name of the group the file or directory should be affiliated with, and filename is the name of the file or directory whose group is to be changed. So if I wanted to make this article belong to the dpadmin group (SSCC staff) I would type
> chgrp dpadmin 7-7.htm
This is assuming /usr/global/web/sscc/pubs (where this document is located) is my current working directory. Otherwise I would have to specify that path.
You can change the group affiliations of more than one file at a time using wildcards. For example putting an asterisk (*) as the filename will change the group affiliation of all the files and directories in the current directory. You can also change the group affiliation of everything in any subdirectories of the current directory with the -R (recursive) option. So if I wanted to change everything under /usr/global/web/sscc/pubs (the SSCC Knowledge Base) to belong to the dpadmin group, I would type
> chgrp -R dpadmin *
In many cases all the files in a directory should belong to a certain group. For example, everything in /project/hauser should belong to the hauser group. By default, new files will belong to the primary group of the person who created the file. However, you can set group affiliations to be "sticky" for a given directory, meaning new files created in that directory will automatically belong to the same group as the directory. You can set this by typing:
> chmod g+s directory
This can save a lot of headaches, especially since when many programs save a file they actually delete the old file and create a new one, potentially changing its group affiliation. Unfortunately, stickiness is not sticky--you'll need to do this for every new directory you create, even subdirectories of sticky directories.
Changing the Permissions of a File or Directory
Changing the permissions for a file or directory is done with the chmod command. Like chgrp, you first specify the change you want to make, then the file or files you want to change. Wildcards like the asterisk (*) and the -R option work in exactly the same way.
You specify the change you want to make by first stating who you want to change. This can be the owner (u, think user), the group (g), or everyone else (o, think others). Next is whether you are adding (+) or taking away (-) a permission. Finally, you specify which permission you are changing: read (r), write (w) or execute (x). For example, if I wanted to give the group permission to edit (write) this article, I would type
> chmod g+w 7-7.htm
You can do more than one permission change at a time by listing them all with commas between them (but no spaces). For example if I decided I didn't want the group editing this article after all, but I did want them to be able to read it, I would type
> chmod g-w,g+r permissions.htm
Putting it all Together
Suppose I want a project directory called userserv where myself, Sandra Wald, Caitlin Tefft, and Doug Hemken (the SSCC user services staff) can work on shared files. First I need to email the consultant and request that the directory be created. If I'm on the ball I can at the same time request that a group called userserv be created with myself, Sandra, Caitlin, and Doug as members, and that the new directory should be affiliated with that group. If I do, the userserv directory will be affiliated with the userserv group when it is created. Otherwise I need to log in to Linux myself and type
> chgrp userserv /project/userserv
Now assuming I want to give Sandra, Caitlin, and Doug full access to the directory, I would type
> chmod g+r,g+w,g+x /project/userserv
If I already had some files and subdirectories inside the directory, I would also need to type
> cd /project/userserv
> chgrp -R userserv *
> chmod -R g+r,g+w,g+x *
That will give them full access to all the tables of the directory as well.
Samba Permissions
Samba is the program that makes the Linux file system available to Windows. This is done by defining Windows shares that point to Linux directories. For example the hauserproj share (available as \\sscunix\hauserproj in Windows) points to /project/hauser. However, Samba shares have their own set of permissions, so if someone is supposed to work on files in /project/hauser and wants to do so using the hauserproj share on Windows, they not only need to be added to the hauser Linux group (because that's the group affiliation of /project/hauser), they also need to be added to the group who can use the hauserproj share. So if your group uses a specific Samba share, when you add new people be sure to tell the consultant to add them to the group that can use it as well as your Linux group.
On the other hand, we recently created a generic project share that just points to /project and does not require special permissions to use. So once someone has been added to the Linux group that can work with a project directory, they can access it immediately through the project share. For example, members of the hauser group can map a drive to \\sscunix\project\hauser and see the same files as if they mapped a drive to \\sscunix\hauserproj but without needing to be added to the Samba group. Linux permissions still apply, of course. In most cases just using the generic project share rather than a share that is specific to one project will eliminate the need to worry about Samba permissions.
See Mapping a Drive to a Network Share in Windows for instructions on setting up mapped drives.
If you're using Windows, use Windows Project space
Historically, the SSCC made project space available on our UNIX system before we made it available in Windows. Thus many projects are stored on Linux today simply because, at the time they were created, that was the only place they could be. However, many research groups now work exclusively in Windows. This can create headaches because Windows users are typically not familiar with Linux file permissions, preventing them from sharing files with other group members.
If your research group never uses Linux but still has project space on the Linux file system, consider requesting that SSCC staff move it to the X: (Windows Project) drive instead. This has several advantages: group members will not have to map a new network drive in order to access it, reading and writing will be somewhat faster, and there will be no need to deal with Linux permissions.
The disadvantage is that while Samba makes the Linux file system available to Windows, it cannot make the Windows file system available to Linux. Thus if you need to run Linux programs, you need to use Linux project space. Of course you're welcome to use both: if most of your group uses Windows but you occasionally need to run Linux programs, you can request a small Linux project directory just for those things that need to be accessible from Linux along with your Windows project folder on the X: drive.
Last Revised: 3/15/2007