Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!ccplumb
From: ccplumb@watnot.UUCP
Newsgroups: comp.edu
Subject: Cheating on Programming Assignments
Message-ID: <12853@watnot.UUCP>
Date: Sat, 11-Apr-87 13:16:53 EST
Article-I.D.: watnot.12853
Posted: Sat Apr 11 13:16:53 1987
Date-Received: Sun, 12-Apr-87 03:53:28 EST
References: <248@rruxa.UUCP> <2625@phri.UUCP> <1652@ttrdc.UUCP> <1355@uwmacc.UUCP> <568@cpocd2.UUCP>
Reply-To: watmath!watnot!ccplumb (Colin Plumb)
Organization: U of Waterloo, Ontario
Lines: 44
Confusion: U. of Waterloo, Ontario

nate@cpocd2.UUCP (Nate Hess) says (in <568@cpocd2.UUCP>):
>oyster@unix.macc.wisc.edu.UUCP (Vicarious Oyster) says (in <1355@uwmacc.UUCP>):
>>levy@ttrdc.UUCP says (in <1652@ttrdc.UUCP>):
>>>roy@phri.UUCP (Roy Smith) says: (in <2625@phri.UUCP>):
>>>> prepare an executable file called, for example, assignment1 in his home
>>>> directory which the prof will then run using his own data set.
>>>
>>>Can you say "Trojan Horse"?  I know you could....
>>
>>  Can you say "Academic Probation"?  I knew you could...
>
>One way around this problem is for the student to have a source file,
>assignment1.p, say, in his/her home directory, which the prof could then
>copy, compile, and run.
>
>This would also allow the professor to see what, if any, compiler
>errors, warnings, and/or messages each student's program generates.

Having the prof compile the program personally still doesn't save
him from trojan horses completely.  It makes it possible to find them,
but who wants to do all that work for a whole class?

I could just use a deeply nested mess of #includes, which has a
macro somewhere in the bottom which forks off a shell script.
This shell script (now running as the prof) would then create a
setuid prof shell (in a directory where it's untraceable - /tmp
will do, but globally writeable directories that don't get cleaned
out can be found with a little work) and start up a setuid student
program which would change the culpable .h file and clean up any
footprints.

Once all traces are cleaned up (don't forget to change the time on
the setuid shell, so it can't be correlated with the last accessed
time of the various executables, and recompile your submitted program
in toto, so noone can use adb to look for fork() and exec() calls)
there's no way to find the culprit.

As many have said, if you *really* want to break Unix security,
there's precious little stopping you.
--
	-Colin Plumb (watmath!ccplumb)

Silly quote:
That's a horse of a different feather.