liam@cs.qmc.ac.uk (William Roberts) (10/24/86)
>Access is a program I wrote to handle a not-so-infrequent situation that >standard UNIX file permissions didn't seem to address, quite. Given a >set of users (e.g. students in a class) which are to be protected from >each other (can't read or destroy each other's homework, for example) >and one or more "senior" logins (e.g. the teacher of the class, TAs for >the class) arrange for these (individually protected from each other) >logins to all be accessible to the senior, administrative logins. The >senior logins aren't to be given root permissions. I couldn't figure a >way to do this with the standard UNIX permissions system. The way to do this is to use UNIX group permissions. In 4.2 BSD (can't speak for any other flavour or version), the /etc/passwd file contains both the UID and GID of each user. Each file has both a user (UID) and a group (GID) that "own" it, and the file permissions distinguish between permissions for the UID that owns the file, permissions for people who belong to the group that owns the file, and all the rest of the universe (known collectively as "others"). It is not necessary for the user who owns the file to be in the group that owns it. The problem you describe is covered by the case: % ls -lg ~astudent total 5 -rw-r----- 1 astudent seniors 341 Fri Oct 24 12:13:14 asgnmt.c drwxr-x--- 2 astudent seniors 512 Fri Oct 20 10:01:43 private etc etc. If the teacher and other suitable people have GID "seniors", then they can read the files in this directory, as can user "astudent" who is in group "students". Her classmates, also in group student, are neither owner nor group owner of these files, so they have to put up with the "others" permissions i.e. none whatsoever. This achieves the desired effect. In order to make this state of affairs automatic, two other measures must be taken: 1) The student home directories must have group ownership "seniors" 2) The umask for each student must be set to 027. Files inherit the group ownership of the directory in which they are made (I believe - references in the manual anyone?), so measure (1) causes student files to belong to group "seniors" by default. The second measure is definitely a 4.2ism: when a file is created, the file permissions are ANDed with NOT(umask), so 027 (octal) means "remove group write permission and all permissions for other". The system default umask is set by the login program to 022, but the command "umask 027" in start-up files like .login, .cshrc and .profile will have the necessary effect. The advantages of doing it like this are many and various: there is no need for dodgy "su" programs, the students can selectively make some of their files more public (or less public) and the whole thing is fairly easy to understand. If you need to have different groups for different courses (e.g when 3rd year students act as supervisors on 1st year courses), then you can use the 4.2 BSD facilities for putting individuals in more than one group (see group(5) in the manual). This is the system we use in the Computer Science Department here at QMC and (touch wood) it does seem to be working nicely.