Permissions and File Sharing

In Tipsheets Vol. 1, No. 6 and Vol. 2, No. 8 we talked about file permissions in the context of being security conscious. The subject is worth revisiting in the sense of sharing files with others, perhaps for users working on a group project. By using the group permissions you can share directories and files with other users, without having to share with everyone else on the system. You may recall that files and directories have three levels of protection, the user, the group and everyone else. You certainly know who you are, and you know who everyone else is, but what is your group? If you do a special version of the ls command, you will see the group ownership of your files. Try this:

ls -g

The output should resemble this:

-rw-r--r-- 1 students 20   Dec 28 16:53 file_one 
-rwxr-x--- 1 students 1254 Dec 10 13:42 program

As a reminder, the first information gives the (r)ead, (w)rite and e(x)ecute permission for the user, group, and others, respectively. The field that has the word "students" indicates that this is the group membership of these files. In this example, any of the permissions that are set for the group will apply to all users in the group, "students". On the Bama system, this includes all the students, as you might guess. Other possible groups include "facstaff", "orgs", and "staff", among others. In the example, "program" is set as executable for "user" and "group" but not for others. This means, that anyone in a group other than "students", such as "facstaff", cannot execute this file. To find out which group or groups you are in you can type the command "groups".

So, the way a group of people might work together on a project is for the individuals to be added to a special group made up for that purpose. Then the ownership of all directories and files associated with the project would be set to the group, the group permissions would all be turned on, and the permissions for others would be turned off. The group would have to be set-up originally by the system administrator. This can be done for appropriate groups by sending email to help.desk@ua.edu.

Commands That Work with Groups

When you create a file it will automatically have the group ownership that you have. This will be the group you are assigned in your login (see the list mentioned above) unless you change it with the "newgrp" command, like this:

newgrp groupname

where groupname is the name of the new group. You can only change to groups you belong to.

Once a file or directory has been created it is still possible to change the group ownership. In this case you would use the "chgrp" command, like this:

chgrp groupname filename

where groupname is the name of the group and filename is the name of the file or directory. As with the "newgrp" command, you can only change the group ownership to groups to which you belong.

There may be some cases where you want to give group members write-permission to a common, group directory but still let them retain control over the files they write there. This is accomplished by using the "sticky bit". This is a piece of the permission information that, when set, indicates that the owner and group of a file added to a directory remain the same as the owner and group of the person who wrote the file. So, a user can put files in an area that is accessible to the group, but the files can be protected against being written to or deleted by others in the group. Without the sticky bit, when a member writes a file to a group directory, it will have the same owner and group as the directory, which, in this scenario, would mean that the group had write permission. To set the sticky bit for a directory type

chmod +t dirname

where dirname is the name of the directory.

If you want to make sure that files a group member puts in this common directory have the correct group permission, you might want to set the "setgid" bit on the directory permissions. When this is set, files that are added will belong to the same group as the directory. If this bit were not set, then the user would have to remember to execute a "newgrp". If, however, the common directory only had write-permission set for the group and not other users, then this would force the user to do a "newgrp" and the "setgid" would not be necessary. To set the "setgid" bit on the directory you would type

chmod g+s dirname

where dirname is the name of the directory

Well, these are some ideas to consider when trying to work with groups of people, especially where you don't want the information to be readable by all users or you don't want all users to write to your group directory. This scheme is not the perfect answer to people needing to work in groups. There are limits to the number of groups to which an individual may belong and keeping track of your current group and sorting out all the permissions can be confusing. The limit on the number of groups presumably can be gotten around by using group passwords; something we haven't been implementing on Bama. Preventing the confusion is something we can't do much about.

© 1999, The University of Alabama. The information included here is for the University of Alabama central computing facility as it was configured on the document date. It may or may not apply to other Unix systems.

February 22, 1999 Vol. 3 Index Back to Vol. 3, No. 6 Ahead to Vol. 3, No. 8		Search:

	E-mail Internet Access Software Assistance Computer Labs Software Licensing Web Publishing Calendaring Computer Security Unix Training

	Permissions and File Sharing In Tipsheets Vol. 1, No. 6 and Vol. 2, No. 8 we talked about file permissions in the context of being security conscious. The subject is worth revisiting in the sense of sharing files with others, perhaps for users working on a group project. By using the group permissions you can share directories and files with other users, without having to share with everyone else on the system. You may recall that files and directories have three levels of protection, the user, the group and everyone else. You certainly know who you are, and you know who everyone else is, but what is your group? If you do a special version of the ls command, you will see the group ownership of your files. Try this: `ls -g` The output should resemble this: -rw-r--r-- 1 students 20 Dec 28 16:53 file_one -rwxr-x--- 1 students 1254 Dec 10 13:42 program As a reminder, the first information gives the (r)ead, (w)rite and e(x)ecute permission for the user, group, and others, respectively. The field that has the word "students" indicates that this is the group membership of these files. In this example, any of the permissions that are set for the group will apply to all users in the group, "students". On the Bama system, this includes all the students, as you might guess. Other possible groups include "facstaff", "orgs", and "staff", among others. In the example, "program" is set as executable for "user" and "group" but not for others. This means, that anyone in a group other than "students", such as "facstaff", cannot execute this file. To find out which group or groups you are in you can type the command "groups". So, the way a group of people might work together on a project is for the individuals to be added to a special group made up for that purpose. Then the ownership of all directories and files associated with the project would be set to the group, the group permissions would all be turned on, and the permissions for others would be turned off. The group would have to be set-up originally by the system administrator. This can be done for appropriate groups by sending email to help.desk@ua.edu. Commands That Work with Groups When you create a file it will automatically have the group ownership that you have. This will be the group you are assigned in your login (see the list mentioned above) unless you change it with the "newgrp" command, like this: `newgrp groupname` where `groupname` is the name of the new group. You can only change to groups you belong to. Once a file or directory has been created it is still possible to change the group ownership. In this case you would use the "chgrp" command, like this: `chgrp groupname filename` where `groupname` is the name of the group and `filename` is the name of the file or directory. As with the "newgrp" command, you can only change the group ownership to groups to which you belong. There may be some cases where you want to give group members write-permission to a common, group directory but still let them retain control over the files they write there. This is accomplished by using the "sticky bit". This is a piece of the permission information that, when set, indicates that the owner and group of a file added to a directory remain the same as the owner and group of the person who wrote the file. So, a user can put files in an area that is accessible to the group, but the files can be protected against being written to or deleted by others in the group. Without the sticky bit, when a member writes a file to a group directory, it will have the same owner and group as the directory, which, in this scenario, would mean that the group had write permission. To set the sticky bit for a directory type `chmod +t dirname` where `dirname` is the name of the directory. If you want to make sure that files a group member puts in this common directory have the correct group permission, you might want to set the "setgid" bit on the directory permissions. When this is set, files that are added will belong to the same group as the directory. If this bit were not set, then the user would have to remember to execute a "newgrp". If, however, the common directory only had write-permission set for the group and not other users, then this would force the user to do a "newgrp" and the "setgid" would not be necessary. To set the "setgid" bit on the directory you would type `chmod g+s dirname` where `dirname` is the name of the directory Well, these are some ideas to consider when trying to work with groups of people, especially where you don't want the information to be readable by all users or you don't want all users to write to your group directory. This scheme is not the perfect answer to people needing to work in groups. There are limits to the number of groups to which an individual may belong and keeping track of your current group and sorting out all the permissions can be confusing. The limit on the number of groups presumably can be gotten around by using group passwords; something we haven't been implementing on Bama. Preventing the confusion is something we can't do much about. © 1999, The University of Alabama. The information included here is for the University of Alabama central computing facility as it was configured on the document date. It may or may not apply to other Unix systems.
Copyright © 1998-2004 The University of Alabama \| Disclaimer \| Contact: Help.Desk@ua.edu