battle@alphard.cs.utk.edu (David Battle) (01/03/90)
I would like to have an accounting utility which will keep not only the name of the command run but also the arguments, especially for commands typed at a shell by a human (as opposed to coming from a command file). Is there an existing utility which does this? If not, can someone provide me with info on how to begin writing such a utility? I would presume it would be similar to "ps", digging through kmem to get the command strings, or perhaps it would be better to make a front end to a shell (similar to what script does)? Comments? By the way, this is for Ultrix and doesn't have to be portable to other flavors of unix. -David L. Battle battle@battle.esd.ornl.gov battle@utkux1.utk.edu
gorham@uiucme2.me.uiuc.edu (Gorham P. Miscall) (01/03/90)
In article <1527@utkcs2.cs.utk.edu> battle@alphard.cs.utk.edu (David Battle) writes: >I would like to have an accounting utility which will keep not only >the name of the command run but also the arguments, especially for commands >typed at a shell by a human (as opposed to coming from a command file). >Is there an existing utility which does this? If not, can someone provide >me with info on how to begin writing such a utility? I would presume it would >be similar to "ps", digging through kmem to get the command strings, or perhaps >it would be better to make a front end to a shell (similar to what script >does)? Comments? By the way, this is for Ultrix and doesn't have to be >portable to other flavors of unix. > > -David L. Battle > battle@battle.esd.ornl.gov > battle@utkux1.utk.edu The following was taken out of the January issue of UNIX World. It works very well for me: This captures all I/O of a terminal session to "Capture.file" tee -a Capture.file | sh -i 2>&1 | tee -a Capture.file Hope this does the trick for you! ****************************************************************************** * Gorham P. Miscall "On a clear disk you can seek forever" * * gorham@uiucme2.me.uiuc.edu -anonymous *
jfh@rpp386.cactus.org (John F. Haugh II) (01/03/90)
In article <1990Jan2.180615.28396@ux1.cso.uiuc.edu> gorham@uiucme2.UUCP (Gorham P. Miscall) writes: >In article <1527@utkcs2.cs.utk.edu> battle@alphard.cs.utk.edu (David Battle) writes: >>I would like to have an accounting utility which will keep not only >>the name of the command run but also the arguments, especially for commands >>typed at a shell by a human (as opposed to coming from a command file). > > The following was taken out of the January issue of UNIX World. It >works very well for me: > > This captures all I/O of a terminal session to "Capture.file" > > tee -a Capture.file | sh -i 2>&1 | tee -a Capture.file > >Hope this does the trick for you! Not likely. This command will have the nasty side-effect of causing your standard input and standard output to no longer be terminals. Try editing a file using vi in such a capture program. For a capture program to really work it needs to use pty's. Pipes won't cut it. The trick is to grab a pair [ one for input, the other for output ] of ptys. On one end you read from the original input in raw mode, and shove it through the pty. The other end reads the output of the pty. Both ends have a file open for append which they duplicate all of the characters each sees into it. Writes on this capture file are unbuffered to preserve the relationship between the characters. For more details see the Berkeley script command. I also have one using pipes, but as I mentioned above, it doesn't work completely. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
bzs@world.std.com (Barry Shein) (01/04/90)
Gak, I'm amazed at the bad advice this poor fool is getting, I think
people don't understand what he's really after, probably spying on
users to trap certain hackery. I assume that's what you mean,
otherwise just use "script".
Here's a few realistic approaches, none of which will work for you:
1. Modify the shell source to punch each command line as entered,
syslog() might be a way to do this but that's up to you, the problem
will be punching to a file which is protected from general write
access. One possibility is making it setuid and have main open the
accounting file and then drop setuid. You'll have to be careful about
anyone inheriting this open file descriptor.
The hole is all forks/execs started without the shell, if I were a
cracker and knew you were doing this I'd cobble together my own shell
in about 1/2 hour, I probably don't need anything but read line, break
into strings, fork/exec (don't need indirection, shell programming
etc.) Even simpler, any number of source distributable shells, etc.
2. Sample frequently a "ps auww", probably trim and send to a file.
This will only catch commands you catch, depends on sampling frequency
and how fast your ps can rip through the system. You can write your
own process groveler but it probably won't be much faster than just
doing a popen() on ps, most of ps's time is spent groveling through
swap etc., most people learn this the hard way. Anyhow, this won't
work very well except for reasonably long running commands.
3. Put it into exec in the kernel, link it to the current accounting
system. This is the only way to do what you want reliably and chances
are good your system won't do a whole lot else (not to mention the
disk space.) Might be nice to have some way to limit such a facility
to certain users, commands etc. via (priv'd) ioctls.
Like I said, I doubt any of those are what you want (well, you *want*
3, but you don't have sources or don't want to be bothered with such a
project, ah well, we're only arguing about the price :-)
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzsjfh@rpp386.cactus.org (John F. Haugh II) (01/05/90)
In article <1990Jan3.225009.17563@world.std.com> bzs@world.std.com (Barry Shein) writes: >Gak, I'm amazed at the bad advice this poor fool is getting, I think >people don't understand what he's really after, probably spying on >users to trap certain hackery. I assume that's what you mean, >otherwise just use "script". The same technology which brings us "script" works for spying as well. You are looking for a complex solution where easy ones probably exist as well. To see how this works, consider the behavior of putting script onto a port which the hacker is on, or likely to be on. It is a trivial matter to read from the port and write to a pty with a shell on the other end of the pty. This works equally well, regardless of whether the user is co-operating or not ... -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org