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.