This page describes a method for allowing a defined set of users to edit shared files. In this method, a special group is created, and a set of users is added to it. A directory is created that is owned by the group, with permissions set such that all members of the group can create files (and sub-directories). The directory can also have a special setting known as "set group ID". This means that all files created in it will automatically inherit the group ownership that the directory has.
From a security standpoint, this method is preferable to account sharing.
In order for this method to work well, users should understand the basics of UNIX file ownership and permissions and should take care to make sure that newly created files have the proper permissions so that other members of the group may access them.
This method requires that the system administrator establishes a group with the desired users as members.
In UNIX, access to files is controlled by two independant concepts: file ownership and file permissions. There are two types of file ownership; each file is owned by a single user and a single group. other describes users who are not the owner or in the group that owns the file. read, write, and execute permissions are set independantly for a file's onwer, group, and other. Thus, restricting or permitting file access requires managing both file ownership and file permissions
There are many sources of information about using UNIX file ownership and permissions; Google returns many results: http://www.google.com/search?q=unix+file+ownership http://www.google.com/search?q=unix+file+permissions
Redhat advocates a group scheme that they call "user private groups", this is discussed in their documentation
See these recommended links for overviews of UNIX file ownership and file permissions
A user's group membership is established by the system administrator. To see which groups a user belongs to, issue the command
% groups username
You can list the system's raw group information by issuing the command (this is the command for systems which use NIS, like the HEP Linux cluster)
% ypcat group
In order to allow group members to write to a file, set the group ownership of the file to the proper group using the chgrp command
% chgrp groupname filenamethen set the file permissions so that everybody in the group can read and write(and execute) the file
% chmod g+w filename % chmod g+r filenamethere are other ways to use the chmod command, but the above is the simpliest. The first command adds (+) group write permission and the second command adds group read permisisons. To remove a permission, use - instead of +.
Here is an example of changing the group ownership and permissions on a file
% ls -l -rw-r--r-- 1 rockwell users 0 Dec 4 14:56 afile % chgrp agroup afile % chmod g+w afile % ls -l -rw-rw-r-- 1 rockwell agroup 0 Dec 4 14:56 afileThe group was changed from "users" to "agroup". To change the group of a file, you have to be the owner of the file (having write permissions via group membership is insufficient) and you have to be a member of the group you are assigning. You can get around the ownership requirement by making a copy of the original file. Note that on typical Linux systems, regular uses can never change the ownership of a file (i.e. the chown command is only useful to the system administrator).
The umask is bitmask which controls the default permissions that newly created files have. The umask is set when you login. You can see what it is by issuing the command "umask". You also change it with the umask command, for example "umask 022".
Your default is normally 022. A umask of 022 means that newly created (non-executable) files will have read,write permissions for the owner and read-only for group and other. If you change your umask to 002, newly created files will have the group write permission.
Here is an example of creating files using different umasks
% umask 022 % touch file1 % umask 002 % umask 002 % touch file2 % ls -l -rw-r--r-- 1 rockwell users 0 Dec 4 14:28 file1 -rw-rw-r-- 1 rockwell users 0 Dec 4 14:28 file2
A directory can be given a setting called "set group ID". This means that when new files are created in it, the files will be owned by the directory's group instead of the user's default group. Newly created sub-directories also assume the parent directory's group and also get the set group ID property. This setting is affected with the command "chmod g+s dirname".
Here is an example of creating new files in a set group ID directory, not that umask is set to 002
% ls -l /home drwxrwsr-x 4 agroup agroup 4096 Dec 4 15:43 agroup % cd ~agroup % umask 002 % touch afile % touch adir % ls -l drwxrwsr-x 2 rockwell agroup 4096 Dec 3 15:25 adir -rw-rw-r-- 1 rockwell agroup 0 Dec 4 12:10 afile
Some problems may arise while using this method.
One issue is that certain UNIX command preserve file ownership and permissions. For instance, "mv" and "cp -p" both preserve file permissions. Regular "cp" does not. So be aware when moving files into the shared group directory.
Another issue is that some programs ignore the umask - the Mozilla web browser for instance does not follow the shell's umask and instead always uses 066, so files downloaded and saved with Mozilla will not even be group readable. Verify and set the desired permissions on downloaded files by hand.
Issues may arise with file sharing to Windows via SAMBA, this is untested and normally won't be used.
Finally, this method does not provide for file locking or concurrent revision - members of the group will have to be careful to not undo other's work. Other methods, such as CVS, are more appropriate if many people will be working on the files at once.
Here is an example of establishing a shared area for a workgroup. In the following, the group "agroup" will be created with UID and GID 1501. The workgroup will be given a non-login account in /etc/passwd. This allows a home directory, accessible as ~agroup, to be created. Most workgroup files will be important and should be backed-up, so ~agroup will be added to the normal backups.
Edit /etc/passwd, the password field is filled with an x, and the shell is set to /bin/false - nobody will be able to login with this account. Add a line such as:
agroup:x:1501:1501:Shared Workgroup:/home/agroup:/bin/false
Edit /etc/group, add a line such as:
agroup:x:1501:user1,user2,userN
Create the home directory:
% mkdir /disk3/home2/agroup
Set the permissions on the directory, note that the directory is group writable and "set group ID".
% chown agroup:agroup /disk3/home2/agroup % chmod 2775 /disk3/home2/agroup
Add the directory to /etc/auto.home, so that is will be available on the cluster.
Update yp - go to /var/yp and execute "make".
Add the directory to the backup list in /etc/amanda/STD/disklist.