Xref: utzoo comp.unix.wizards:10977 comp.os.misc:504
Path: utzoo!attcan!uunet!husc6!uwvax!rutgers!cmcl2!lanl!unm-la!unmvax!turing.unm.edu!mike
From: mike@turing.unm.edu (Michael I. Bushnell)
Newsgroups: comp.unix.wizards,comp.os.misc
Subject: Re: tracing system calls
Keywords: truss syscall & trace
Message-ID: <1195@unmvax.unm.edu>
Date: 4 Sep 88 08:53:42 GMT
References: <21606@ccicpg.UUCP> <7622@boring.cwi.nl> <2040@cuuxb.ATT.COM> <66624@sun.uucp> <7460@bigtex.uucp>
Sender: news@unmvax.unm.edu
Reply-To: mike@turing.unm.edu.UUCP (Michael I. Bushnell)
Organization: University of New Mexico, Albuquerque
Lines: 26

In article <7460@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes:
>
>I don't want to flame Sun over trace though: that is incredibly
>useful.  I am curious about implementation though: if it will display
>the data for write(2) it would seem a security hole unless disabled
>for suid processes.  Is there any possible way to write a similar
>program under SysVr3 without kernel modifications?

Trace(1) is undoubtably done using ptrace(2) in combination with an
option added by SUN that stops the process upon execution of and upon return
from system calls.   If you don't modify your kernel to have this feature,
then trace(1) becomes a matter of tracing entry points to the C library...
that will find system calls executed the "normal" way, but not freaky things
like people writing code (on the fly) into their data segment and then
executing it.

And, since it probably uses ptrace(2), setuid is ignored for the process.


-- 
                N u m q u a m   G l o r i a   D e o 

			Michael I. Bushnell
			HASA - "A" division
			mike@turing.unm.edu
	    {ucbvax,gatech}!unmvax!turing.unm.edu!mike