Xref: utzoo comp.unix.wizards:10928 comp.os.misc:499
Path: utzoo!attcan!uunet!husc6!mailrus!ames!oliveb!sun!terra!brent
From: brent%terra@Sun.COM (Brent Callaghan)
Newsgroups: comp.unix.wizards,comp.os.misc
Subject: Re: tracing system calls
Keywords: truss syscall & trace
Message-ID: <66892@sun.uucp>
Date: 5 Sep 88 16:41:52 GMT
References: <21606@ccicpg.UUCP> <7622@boring.cwi.nl> <2040@cuuxb.ATT.COM> <7460@bigtex.uucp>
Sender: news@sun.uucp
Lines: 31

In article <7460@bigtex.uucp>, james@bigtex.uucp (James Van Artsdalen) writes:
> 
> > 	$ trace date
> 
> I count 8 closes, 6 mmaps, 5 opens, 3 reads, 2 munmaps, 1 write...
> 
> What on earth does all of this have to do with printing the date and
> time???  getgid?  ioctl?  That's 36 system calls.

Most of the system calls in this example are taking care of the
mapping in of the shared libraries.  The overhead is the same
for any dynamically linked process - it just looks top-heavy for
a program like "date".  It's the classical time/space tradeoff:
it takes a little longer to get to the gettimeofday() but date
has a much smaller executable, uses the latest version of the
C library, and shares the same C library code as all the other
resident processes.

> 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.

You're right.  You can't trace suid processes unless you are
also superuser.  The trace command is bound by the restrictions
already on the ptrace() system call.  A suid program will run but
it won't have any of its suid-ness.  Neither can you trace other
people's processes - they must be yours.

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 6188