liam%cs.qmc.ac.uk@BRL.ARPA (William Roberts) (04/20/87)
>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.
haynes@ucscc.UCSC.EDU (99700000) (04/20/87)
If you have kernel source, there is a hack of a few lines done by Berkeley Computer Center that sez if uid == gid then the user is considered the "group master" for the class (group) and has all privileges over files in that group. So it doesn't depend on the directories having the "right" protection mode and the umask being right.
john@xanth.UUCP (04/21/87)
In article <6973@brl-adm.ARPA>, liam%cs.qmc.ac.uk@BRL.ARPA (William Roberts) writes: > 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), Strange - I heard exactly this before from someone else (and corrected it then, but I can't remember if it was by mail or news). The *first*, that files inherit the group from the parent directory, is a Berkeleyism. Under v7, System III, System V (at least older ones), and any other UNIXes I know of, the group of the file is the effective gid of the creator. Does anyone know of any other systems that do the Berkeley thing? v8? v9? sVr3? The second measure, umask, has existed since v7, and is in all System Vs, and probably all System IIIs. It is hardly a Berkeleyism. (If it were, it would probably be called creatmask, and be specified in either octal (but not negated), or symbolically, like with chmod, and you would only be able to set it with the csh! (major :-) )) -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 4529 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john
brandon@tdi2.UUCP (Brandon Allbery) (04/23/87)
Quoted from <6973@brl-adm.ARPA> ["Re: Access -- a program to give permissions across logins"], by liam%cs.qmc.ac.uk@BRL.ARPA (William Roberts)... +--------------- | >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 | >logins to all be accessible to the senior, administrative logins. The | | The way to do this is to use UNIX group permissions. In 4.2 BSD | Files inherit the group ownership of the directory in which | they are made (I believe - references in the manual anyone?), +--------------- May be true for BSD, but under System V a file is created with the gid of the creator. I suspect the same is true for BSD, although there may be some kind of setgid-directory semantics to get the effect you describe. ++Brando -- Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon Tridelta Industries, Inc. CSNET: ncoast!allbery@Case 7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET@relay.CS.NET Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home +1 216 974 9210)