Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site im4u.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!qantel!dual!mordor!ut-sally!im4u!jsq
From: jsq@im4u.UUCP (John Quarterman)
Newsgroups: net.cse
Subject: Re: students editing output
Message-ID: <537@im4u.UUCP>
Date: Thu, 19-Sep-85 13:50:12 EDT
Article-I.D.: im4u.537
Posted: Thu Sep 19 13:50:12 1985
Date-Received: Fri, 20-Sep-85 07:00:54 EDT
References: <433@uvm-cs.UUCP> <12378@styx.UUCP>
Reply-To: jsq@im4u.UUCP (John Quarterman)
Distribution: net
Organization: U. Texas CS Dept., Austin, Texas
Lines: 55
Summary: 

In article <12378@styx.UUCP> mcb@styx.UUCP (Michael C. Berch) writes:
>In one class the readers were set up as group-superusers (this was V6)
>and required that the students leave a copy of the source program in a
>certain directory in their account with a certain title, explained how
>modification times worked, and required that the mod time on the program 
>file be before the deadine. Then the readers would su to the account and read, 
>compile, and execute the program, and leave the grade and comments in a 
>file or mail them.
>
>This worked quite well. (Uh, actually, there was some minor silliness
>involving the group-superuser's PATH, which included "." first. One
>enterprising student [OK, I admit it...] who had completed his program
>late improvised by writing a "version" of ls(1) that, er, fibbed about 
>mod times. At a later date, somebody else wrote a program that took, ah,
>certain liberties with unprotected inodes.  But those are stories for a
>different list . . .)

You can avoid most protection problems by having the students mail the
program to the grader, who runs them.

Or, if mail is too inefficient, the grader can have a subdirectory for
the students to put their completed output in.  If you have the
directory sticky bit (prevents deleting files by anyone but the owner),
set the modes on the subdirectory to sticky, writable by group,
readable only by grader (the owner).  If you don't have the directory
sticky bit, make subsubdirectories for each student, owned and writable
by the student, and readable only by the student and a group the grader
is in but the students aren't.

If the grader runs the programs by a loop like

#! /bin/sh
for students in `cat list`
do
	echo $student
	ls -l sub/$student/prog.c	# to check submission date
	more sub/$student/prog.c	# inspect for correctness and bombs
	read ga
		# dag's timeout suggestion would be useful here
	cc -o prog sub/$student/prog.c
	./prog
done

there's no problem with PATH, because the grader never executes with .
in a directory which the students can modify.  Also, the grader isn't
rummaging around in students' directories and thus isn't tempted to
mess with their private files.  (How come everyone is worried about
honesty of students, but trusts graders implicitly, even though graders
are usually students?)

This scheme requires no special privileges by the grader, and no
intervention by system staff after the group(s) is(are) provided.
-- 
John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  jsq@sally.UTEXAS.EDU, formerly jsq@ut-sally.ARPA


Brought to you by Super Global Mega Corp .com