[comp.unix.ultrix] How do I use /dev/trace?

mbr@aoa.UUCP (Mark Rosenthal) (02/06/90)

We have been running Ultrix 3.0 on our 8650 for close to a year.  Three times
in the past two weeks, we have found permissions on /tmp changed.  Naturally,
when that happens, half the programs in the known universe stop functioning.

I'd like to enable the SYS_TRACE option in the kernel, and write a daemon to
watch for chmod's on /tmp and report whatever information is available about
the process.  I've looked at the man page trace(5) and the include file
/usr/sys/h/systrace.h for clues as to how to use the trace device driver.
The information available is sketchy, to say the least.  Does anyone out there
have better documentation on how to use this?  Any examples?

My specific questions so far are:

 1) What ioctl's do I call, in what order, to indicate that I'm interested
    in chmod() sys calls?

 2) Do I pass a "trace" structure (as defined in systrace.h) as the third arg
    to ioctl()?  If not, what do I pass?  If so, that structure has positions
    for 16 pids, 16 uids, 16 syscalls, and 16 pgrps, but no places to store
    counts of the number of slots in use for each type of slot.  How does the
    driver know which slots contain data I'm interested in?  Is it based on
    the value in the slot?  If so, what value should I use to fill in the slots
    I'm not using?

 3) What are the "IOTR_GET..." ioctl() calls used for?  What about
    "IOTR_SET..."?  What is the meaning of "GET" vs. "SET" in this context?

 4) Once I've done the required ioctl()s to select the items I want to trace,
    I assume I read from the file descriptor.  Where can I find documentation
    on the format of the data that read() will return in the buffer?

Any help would be appreciated.
-- 
	Mark of the Valley of Roses
	...!bbn.com!aoa!mbr

grr@cbmvax.commodore.com (George Robbins) (02/07/90)

In article <1148@aoa.UUCP> mbr@aoa (Mark Rosenthal) writes:
> We have been running Ultrix 3.0 on our 8650 for close to a year.  Three times
> in the past two weeks, we have found permissions on /tmp changed.  Naturally,
> when that happens, half the programs in the known universe stop functioning.

I had a similar problem here, and it turned out to be mostly confusion.

What happened was that for some reason I was doing a newfs for the /tmp parition
and then mounting it.  The protection for /tmp directory that I was mounting the
partition on was 777, but when newfs creates a file system, it apparently makes
the "root" entry on the new filesystem have 755'is protection and when you mount
the new filesystem, this is what you get.

Anyway beyond trying to remember to do a newfs/mount/chmod when preparing a new
/tmp or /usr/tmp filesystem, I also stuck a chmod 777 /tmp /usr/tmp after the
mount -a in /etc/rc to protect against future failing.

Please post anything you find out out the sys_trace stuff.  I'm curious.
-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)

maj@cl.cam.ac.uk (Martyn Johnson) (02/08/90)

My understanding (possibly incorrect) is:

>1) What ioctl's do I call, in what order, to indicate that I'm interested
>   in chmod() sys calls?

IOTR_SET... the things you are interested in, and then just read.

>2) Do I pass a "trace" structure (as defined in systrace.h) as the third arg
>   to ioctl()?  If not, what do I pass?  If so, that structure has positions
>   for 16 pids, 16 uids, 16 syscalls, and 16 pgrps, but no places to store
>   counts of the number of slots in use for each type of slot.  How does the
>   driver know which slots contain data I'm interested in?  Is it based on
>   the value in the slot?  If so, what value should I use to fill in the slots
>   I'm not using?

No, "struct trace" is a kernel structure. (My copy of systrace.h has
a comment to that effect).  You pass over an integer for things like
SETON, and an array of integers for things like SETPIDS.  Unused entries
should be zero, I think.

>3) What are the "IOTR_GET..." ioctl() calls used for?  What about
>  "IOTR_SET..."?  What is the meaning of "GET" vs. "SET" in this context?

The "GET" calls just return the system's idea of what you "SET".

>4) Once I've done the required ioctl()s to select the items I want to trace,
>   I assume I read from the file descriptor.  Where can I find documentation
>   on the format of the data that read() will return in the buffer?

You get back human readable text, as printed out by the "trace" command.
Format should be obvious; unfortunately the output is often of limited
use because it prints out addresses without telling you what they point to.

By the way, you can of course trace the trace command to see what it
does by way of ioctls.  For example:

 trace trace -f /dev/null cat /etc/motd
 
will trace the trace command setting up tracing of the cat.

Martyn Johnson
University of Cambridge Computer Lab
Cambridge UK.