allbery@ncoast.UUCP (Brandon Allbery) (01/01/70)
As quoted from <1196@bsu-cs.UUCP> by dhesi@bsu-cs.UUCP (Rahul Dhesi): +--------------- | In article <4763@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: | >I don't believe it -- *Minix* wins this round!!! You see, the FS process, | >which implements the file system, *is* a user mode process. Yes, it is | >loaded with the kernel, but it doesn't have to be... | | Some clarification is needed here. By "user mode" do you mean "not a | part of the kernel"? I don't think the 8086 CPU has a user mode and a | privileged mode, so everything runs in user mode. +--------------- Both -- my point with the SysV IPC comment is that it can be run as a process on your big UNIX system as well. All the FS process does is implement the semantics of a file system: it takes calls for filesystem functions and issues raw read/write "system calls" to the kernel. This fact is being used to write a networked file system for Minix, based on PC/IP. It could also be used to read "foreign" file systems; e.g. MS-DOS, Xenix, or (unlikely but possible) even VMS. [Writing the driver for the Eagle would be a bit harder...] -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> "...he calls _that_ a `little adventure'?!" - Cmdr. Ryker
root@ozdaltx.UUCP (root) (09/09/87)
A while back I'd asked if anyone has an effective tty watcher or "spy" program, or if they had suggestion as to how such a thing could be accomplished. The most common reply was; use 'cat < /dev/ttyxx', good idea, but the I/O gets confused and can't quite figure out where things are supposed to go. Several versions of *NIX must have had a "hook" or stub in the kernal as more than one person made mention of a 'spy' program that effectivally let you tune in on some one elses tty. To make a long story short, appearently it just can't be done. Looks like MS-DOS wins this round. Thanks for all the reply and suggestions. -- ============================================================ | Scotty | Adapt - Enjoy - Survive | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | ============================================================
dyer@spdcc.COM (Steve Dyer) (09/10/87)
It seems to me that you might be able to hack something up with a
new line discipline which paralleled the normal tty line discipline
with the exception that it replaced the l_input routine with one which,
before calling the standard l_input routine, enqueued its characters
on a private clist of a special device which could be read by the
'spy' program.
Another alternative is to take the public domain pty driver posted recently
and have your gettys running on the pty slaves instead of the serial lines
directly. You would then have a 'telnetd'-like process reading and writing
to the pty controller and the serial device. It could perform the logging
at that point in user mode.
None of these solutions are "free" without requiring some kernel work.
However, the pty solution is pretty simple to implement.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyerjosh@hi.UUCP (Josh Siegel) (09/10/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >A while back I'd asked if anyone has an effective tty >watcher or "spy" program, or if they had suggestion as to >how such a thing could be accomplished. Must have missed this posting... sorry. > >The most common reply was; use 'cat < /dev/ttyxx', good >idea, but the I/O gets confused and can't quite figure out >where things are supposed to go. Very true. Not a good idea. There are lots of better ways of doing this. > >Several versions of *NIX must have had a "hook" or stub in >the kernal as more than one person made mention of a 'spy' >program that effectivally let you tune in on some one elses >tty. It does exist in many forms... 1) Stealbuf - This code reads the input buffers of the user being watched and prints out everything he/she is typing. It doesn't work if they are in raw mode. I don't know who wrote it. 2) Spy - Kinda like a running ps. Fast and clean. Lets you see what commands a user is running. I don't know who wrote it. 3) eye - This is the gem of the bunch. Written for a Sun computer, it watches TCP/IP connections on the ethernet. This lets you see exactly what a user is doing... both input and output. Also, it lets you keep a transcript of the conversation. Triggers exist on it to start watching a connection when the user types "su\n" and when a connection starts up. Very useful for breaking into computer systems and watching what others are doing at any given time. I wrote this one.... > >To make a long story short, appearently it just can't be >done. Looks like MS-DOS wins this round. I am not sure what it won. Sorry... looks like Sun won again ;-) > >============================================================ >| Scotty | Adapt - Enjoy - Survive | >| ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | >============================================================ Before I get mail asking me for copies of the software, let me state my policy. I will not pass out stealbuf or eye to anybody. Stealbuf doesn't work on BSD43 and eye only works on Suns. The current version of eye is nothing but a machine cracker. I don't see a reason to pass this around. In a few weeks, I plan on posting a new version of eye that is a ethernet debugger. I never plan on posting my cracking version. -- Josh Siegel (siegel@hc.dspo.gov) Friends don't let Friends eat Cherry Zingers
kathy@bakerst.UUCP (Kathy Vincent) (09/11/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >A while back I'd asked if anyone has an effective tty >watcher or "spy" program, or if they had suggestion as to >how such a thing could be accomplished. > >To make a long story short, appearently it just can't be >done [ in *NIX ]. Looks like MS-DOS wins this round. Rather depends what your idea of "winning" is, doesn't it? I'd be just as glad to know you couldn't spy on what I was doing - and, no, I don't have anything to hide. Ergo, in my opinion, *NIX would win the round. Kathy Vincent ------> Home: {ihnp4|mtune|codas|ptsfa}!bakerst!kathy ------> AT&T: {ihnp4|mtune|burl}!wrcola!kathy
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/12/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes:
<A while back I'd asked if anyone has an effective tty
<watcher or "spy" program, or if they had suggestion as to
<how such a thing could be accomplished.
Must have missed it; or ignored it assuming that somone more
knowledgeable than I would answer.
<Several versions of *NIX must have had a "hook" or stub in
<the kernal as more than one person made mention of a 'spy'
<program that effectivally let you tune in on some one elses
<tty.
Don't recall having seen them, but can easily believe it. But there's
a better way.
<To make a long story short, appearently it just can't be
<done.
It can be done. The trick is to wade through the kernel data
structures in /dev/kmem until you find where incoming characters from
that tty are being stored, and then watch that space. A program to do
this on 4BSD made the rounds about 3 years ago, causing a flurry
chmod 540 /dev/*mem* /vmunix
chgrp kmem /dev/*mem* /vmunix /bin/ps <and similar things>
chmod 2711 /bin/ps <and similar things>
commands to be issued
<Looks like MS-DOS wins this round.
When did MS-DOS start supporting multiple users so that such a thing
would make sense?
<mike
--
When logic and proportion have fallen soggy dead, Mike Meyer
And the white knight is talking backwards, mwm@berkeley.edu
And the red queen's on her head, ucbvax!mwm
Remember what the dormouse said. mwm@ucbjade.BITNETalvitar@madhat.UUCP (Phil Harbison) (09/12/87)
In article <249@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: > It seems to me that you might be able to hack something up with a > new line discipline which paralleled the normal tty line discipline > with the exception that it replaced the l_input routine with one which, > before calling the standard l_input routine, enqueued its characters > on a private clist of a special device... This is similar to my implementation of a journal feature on a piece of UNIX-based test equipment at Boeing. The Air Force wanted a journal of every keystroke (before input processing) so they could study human factors and write better user interfaces. Each character was put in the raw queue and a copy was also placed in a clist owned by the journal driver if /dev/journal was open. This would be a trivial hack to almost any tty driver. -- Live: Phil Harbison USPS: 3409 Grassfort Drive, Huntsville, AL 35805-5421 Uucp: {clyde,uunet}!madhat!alvitar Bell: 205-881-4317, 205-837-7610x546
jhc@mtune.ATT.COM (Jonathan Clark) (09/12/87)
In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: :A while back I'd asked if anyone has an effective tty :watcher or "spy" program, or if they had suggestion as to :how such a thing could be accomplished. This sounds lie a 3-line stream module to me. What's the problem? In article <15136@hi.UUCP> josh@hi.UUCP (Josh Siegel) writes: : 3) eye - : This is the gem of the bunch. Written for a Sun : computer, it watches TCP/IP connections on the : ethernet. This lets you see exactly what a user : is doing... both input and output. Also, it : :I am not sure what it won. Sorry... looks like Sun won again ;-) You mean that Sun doesn't offer end-to-end encryption? What a piece of junk :-) -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
guy@sun.UUCP (09/12/87)
> :A while back I'd asked if anyone has an effective tty > :watcher or "spy" program, or if they had suggestion as to > :how such a thing could be accomplished. > > This sounds lie a 3-line stream module to me. What's the problem? 1) Few, if any, kernels currently have streams-based tty drivers; S5R3 and S5R3.1's standard tty drivers aren't streams-based. 2) Streams modules live in the kernel, and not everybody can stuff an arbitrary streams module into their kernel. The tty watcher in question requires *some* kernel hacking (unless the vendor of your system has already done that hacking) even with a streams tty. 3) There is no such thing as a non-trivial 3-line streams module. :-) 2) is the major point here; there are no tty watchers that consist solely of a user-mode program that drops on top of a non-hacked UNIX system. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
tim@amdcad.AMD.COM (Tim Olson) (09/14/87)
In article <27816@sun.uucp> guy@sun.uucp (Guy Harris) writes: +----- | > :A while back I'd asked if anyone has an effective tty | > :watcher or "spy" program, or if they had suggestion as to | > :how such a thing could be accomplished. | > | 2) Streams modules live in the kernel, and not everybody can stuff an | arbitrary streams module into their kernel. The tty watcher in question | requires *some* kernel hacking (unless the vendor of your system has already | done that hacking) even with a streams tty. +----- What about a new getty which, instead of exec'ing the user's shell, forks the shell with a pseudo-tty as a terminal, then "watches" the real terminal, sending the characters received & sent both to the pseudo-tty as well as to the snooper? That wouldn't involve hacking the kernal at all.
guy@sun.uucp (Guy Harris) (09/14/87)
> What about a new getty which, instead of exec'ing the user's shell, > forks the shell with a pseudo-tty as a terminal, then "watches" the real > terminal, sending the characters received & sent both to the pseudo-tty > as well as to the snooper? That wouldn't involve hacking the kernal at > all. Unless, of course, your kernel lacks pseudo-ttys.... This also requires you to hack "getty", although you could have the pseudo-"getty" set up the pseudo-tty and run the real "getty" immediately, thus obviating the need to duplicate all of "getty"'s functionality (painful to do without source). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
jhc@mtune.ATT.COM (Jonathan Clark) (09/14/87)
In article <27816@sun.uucp> guy@sun.uucp (Guy Harris) writes: >I wrote: >> This sounds like a 3-line stream module to me. What's the problem? > >1) Few, if any, kernels currently have streams-based tty drivers; S5R3 and >S5R3.1's standard tty drivers aren't streams-based. Well, I *was* being more than slightly facetious when I wrote that comment, although I think you could actually do the guts of it in close to three lines: /* output */ /* input */ mblk_t *dup; mblk_t *dup; dup = copymsg(mp); dup = copymsg(mp); putnext(up_to_monitor,dup); putnext(up_to_monitor,dup); putnext(down_to_device,mp); putnext(up_from_device,mp); [ I'm doing this from memory so the declarations &c may be wrong. ] A small amount of footling around to set this up would be needed, and the surrounding stream module code should be added, but it should be that simple. Unfortunately Guy is absolutely correct about the SVR3 and 3.1 tty drivers not being streams-based and hence this approach not being terribly useful. Perhaps some day this will come to pass (or we'll convert to v8). You could even stick this either above or below the line discipline module, depending on whether you wanted raw characters as typed or what gets passed up the the user process. >2) Streams modules live in the kernel, and not everybody can stuff an >arbitrary streams module into their kernel. True, alas, although one can in all the SVR3-based systems. Errr, can't you? >3) There is no such thing as a non-trivial 3-line streams module. :-) Right again! This one *is* trivial! >2) is the major point here; there are no tty watchers that consist solely of a >user-mode program that drops on top of a non-hacked UNIX system. Yup. This is the type of problem which *ought* to be simple but which isn't in a non-streams environment. Streams was created to be able to handle this sort of thing - following the example above, it succeeds. -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
jc@minya.UUCP (John Chambers) (09/15/87)
> 2) is the major point here; there are no tty watchers that consist solely of a > user-mode program that drops on top of a non-hacked UNIX system. Well, I've done it, and in such a way that it's obviously portable to just about any Unix system. It does take more than just a program. It also takes two unused ports and a cross-over (null-modem) cable between them. What you do is write a little program (I call mine "conn") that takes the names of two ports, opens them, and puts both into raw mode. The program then forks into two processes, each of which starts copying data as fast as it can in one direction. Before doing this, however, the original process has opened an audit-trail file somewhere, and if you give it the right option, it writes messages to the audit trail that includes a transcript of all the traffic, perhaps in the form of a hex dump of each "packet", a timestamp, etc. You can be quite creative here if you wish. The picture (such as can be done with ASCII graphics) is: +---------+ +-------+ | program +<------------->| port1 |<-+ +---------+ +-------+ | | (null-modem cable) +-------+ | +--------------------->| port2 |<-+ | +-------+ V +----+ +---------------+ +conn+====>| Audit file(s) | +----+ +---------------+ ^ | +-------+ +------+ +--------------------->| port3 |<-->| USER | +-------+ +------+ This technique worked just fine a while back when I decided I wanted to study the uucp protocol. It was real easy to get a complete transcript of a uucico session, though figuring out what it all meant wasn't quite so easy. It takes a pretty sophisticated user to figure out that he's actually on port3; everything indicates he's on port1. The only real giveaway might be the somewhat slower response due to the pipelining and auditing. This technique oughta work pretty much anywhere you have a couple of free ports. Writing conn is left as an exercise for the reader. (If you give up, maybe I'll email you a copy of my solution.) -- John Chambers <{adelie,ima,maynard}!minya!{jc,root}> (617/484-6393)
guy@sun.uucp (Guy Harris) (09/15/87)
> although I think you could actually do the guts of it in close to three > lines: > > /* output */ /* input */ > mblk_t *dup; mblk_t *dup; > dup = copymsg(mp); dup = copymsg(mp); > putnext(up_to_monitor,dup); putnext(up_to_monitor,dup); > putnext(down_to_device,mp); putnext(up_from_device,mp); Unfortunately, this means that *everything* going up and down the stream gets sent upstream, if you intend this to be implemented by 1) a streams module that get stuck in above the rest of the tty driver, and 2) a streams driver that implements the tap, with the two joined at the hip. This means that flush messages sent upstream or downstream will also flush the monitor, M_HANGUPs and M_ERRORs will wedge the monitor's stream, M_SIGs and M_PCSIGs will send signals to the monitoring process, etc.. It's straightforward enough to duplicate only the interesting messages with a switch statement, but it does increase the line count a bit more.... (I presume the two "putnext(up_to_monitor, ...)" calls go to different major devices, so that you can distinguish input from output. If not, the complexity goes up a bit more, as the messages need to be stamped to indicate whether they're input or output data.) > >2) Streams modules live in the kernel, and not everybody can stuff an > >arbitrary streams module into their kernel. > > True, alas, although one can in all the SVR3-based systems. Errr, can't you? Well, yeah, it's only a Simple Matter of Programming (you have to have the module first before you can insert it). You also have to have a kernel distributed as a bunch of object modules, rather than as a single executable; I could imagine some packaged systems supplying a prebuilt kernel or kernels. > >2) is the major point here; there are no tty watchers that consist solely > >of a user-mode program that drops on top of a non-hacked UNIX system. > > Yup. This is the type of problem which *ought* to be simple but which isn't > in a non-streams environment. Streams was created to be able to handle > this sort of thing - following the example above, it succeeds. Umm, no, it doesn't. I said "consist(s) *solely* of a user-mode program that drops on top of a *non-hacked* UNIX system." If the tee-junction streams module is in your kernel, then unless your vendor or some third party supplied it, either it had to be hacked up locally for some other purpose (in which case you don't have a non-hacked UNIX system) or it's part of the tty watcher (in which case it doesn't consist solely of a user-mode program. A streams-based tty driver would definitely make it much *easier* to insert this capability, since you wouldn't need to hack the tty driver code itself (which would require source in most, if not all, cases), but it still requires you to stuff code into your kernel. At some point, some vendor may, indeed, offer this streams module; however, until then, implementing a tty watcher requires kernel hacking (which, in turn, generally requires a kernel hacker). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
root@ozdaltx.UUCP (root) (09/15/87)
WoW! I didn't realise I was going to get something started when I wanted a tty watcher. :-). First let me explain my needs/purpose/OS. + I have users that call via modem. Occasionally they get stuck and often can't (or won't) understand the error message they are getting. So it would be nice to watch them and try to see whats wrong. + I'm running SCO XENIX System V on a "clone". Now I know the kernal could be hacked. I don't have the expertise in this area to attempt such a 'fool-hardy' thing. I can make awk play music, but device drivers are a little specialized. When I made the comment, "MS-DOS wins this round"; the true but unfortunate fact of life is that DOS's capibility for "host mode" is very simple to access. As is any other port in the OS. Also, lets face it people, *NIX is not winning any awards for user friendliness. I personally love it, but most users, (not hackers/programers/gurus, etc) want to be able to push a button and not worry about syntax, flags, pipes or redirects. Have you ever considered how cryptic and difficult the "stock" E-mail program is to use? -- ============================================================ | Scotty | Adapt - Enjoy - Survive | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | ============================================================
brianc@cognos.uucp (Brian Campbell) (09/15/87)
In article <5070@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes: ! In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: ! <A while back I'd asked if anyone has an effective tty ! <watcher or "spy" program, or if they had suggestion as to ! <how such a thing could be accomplished. ! ... ! <Looks like MS-DOS wins this round. ! ! When did MS-DOS start supporting multiple users so that such a thing ! would make sense? Well, although the posted message didn't specifically mention it, the original question related to watching what callers were doing on a BBS. [The reply-to field (sysop) hinted at this]. Since there are a number of BBS's running under MS-DOS, and it is quite simple to trap all incoming and outgoing characters, I guess MS-DOS just might have won this round. -- Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc Cognos Incorporated mail: POB 9707, 3755 Riverside Dr., Ottawa, ON, K1G 3Z4 (613) 738-1440 fido: sysop@163/8
dyer@spdcc.COM (Steve Dyer) (09/16/87)
This is silly. A BBS program running under DOS doesn't automatically
"come with" the ability to display what a user has been typing; it has to
be designed that way, especially if the sysop and the user are going
to both be typing at the same time (illusion of multi-programming.)
As far as I can see, DOS or the BBS program would require just as much
hacking to get it to display what you the user types; difference is,
most single purpose BBS already come with this feature. I would be surprised
if you, as an example of "most users", could hack your version of DOS or
its serial driver to make it do what you want. One point must be conceded,
namely, that because of the economics of the DOS world and the simplicities
of the DOS programming model, you are much more likely to find such a feature
available already for sale. This isn't true for Xenix or any other UNIX.
If you needed user typein monitoring within the context of a UNIX-based
BBS system, then of course, there'd be no need for kernel hacking or
special device drivers--the program could be designed to allow monitoring
to a file upon receipt of a signal, or perhaps use some IPC feature of Xenix.
However, given that you wanted the ability to see what the user is typing at
any time, within any program, then one of the suggested kernel-based solutions
is necessary. This hardly seems unreasonable. Of course, the same DOS
model, namely, assigning the console to be COM1, is even less flexible since
you, the operator, would be unable to do anything without a reboot!
It's too bad that, instead of pursuing some of the solutions, you dismiss them
out of hand. It always takes one pioneer to take the risk so that the next
person who needs the same solution can get it "off the shelf."
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyermikel@flmis06.ATT.COM (Mikel Manitius) (09/17/87)
>2) is the major point here; there are no tty watchers that consist solely of a >user-mode program that drops on top of a non-hacked UNIX system. I saw this done on 4.1bsd once, I even had the code that did it. It was a simple program that figured out where the clist struct was for that user's tty driver, and scanned it repeatidly in /dev/kmem for changes. It would output his input line by line. This sort of thing should be feasable on most Unix systems... It's just a pain figuring out where to find his clist, especially given just a tty name. -- Mikel Manitius @ AT&T Network Operations mikel@codas.att.com.uucp | attmail!mikel
terryl@tekcrl.TEK.COM (09/18/87)
In article <198@flmis06.ATT.COM> mikel@flmis06.ATT.COM (Mikel Manitius) writes: >>2) is the major point here; there are no tty watchers that consist solely of a >>user-mode program that drops on top of a non-hacked UNIX system. > >I saw this done on 4.1bsd once, I even had the code that did it. It was >a simple program that figured out where the clist struct was for that user's >tty driver, and scanned it repeatidly in /dev/kmem for changes. It would >output his input line by line. > >This sort of thing should be feasable on most Unix systems... It's just >a pain figuring out where to find his clist, especially given just a >tty name. Actually, if you have a tty name, it is quite trivial to figure out where the C-list structure lives in kernel memory (assuming you have at least read access to /dev/kmem). ****WARNING, WILL ROBINSON!!! SPOILER AHEAD!!!**** It goes like this: first, do a stat(2) on said tty name. Inside of the stat structure returned is a field giving the major/minor number of the tty. Take the major number and use this to index into the cdevsw[] structure. One of the fields in the cdevsw[] structure is a pointer to the FIRST tty structure for the specific RS-232 device. Now use the minor number gotten from the stat(2) call to index into the tty structure. You now have a pointer to the tty structure for the tty name in question. It is left as an exercise to the student to find the appropriate C-list struc- ture. Terry Laskodi of Tektronix
jfh@killer.UUCP (09/18/87)
i'm sure this has been thought of before to solve this problem, but what is wrong with re-writing the /dev/tty driver (i seem to recall the source is very short and simple) so that the minor device number is passed from the open/close/read/write/ioctl calls rather than snatched out of the u-page? you would have your hands on all of the data passed back from the actual calls (say, dzread()) and would then be able to stuff it into a kernel structure. this should be _very_ easy. my only problem is with the close routine as closing the ttywatcher would call the real close and it might not be ready to be closed just yet (although you could finger through the i-node table for the device) i forget the calling sequence for device drivers this week, but most of what you would have to do is pass the same arguments of to the correct routines, and snatch the returned characters from the users address space before/after the call. what am i not seeing? - john. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
martin@iris.ucdavis.edu (Bruce K. Martin Jr.) (09/18/87)
In article <15136@hi.UUCP> josh@hi.UUCP (Josh Siegel) writes: >In article <4263@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >>A while back I'd asked if anyone has an effective tty >>watcher or "spy" program, or if they had suggestion as to >>how such a thing could be accomplished. > >Very true. Not a good idea. There are lots of better ways >of doing this. > True! >It does exist in many forms... > > 1) Stealbuf - > This code reads the input buffers of > the user being watched and prints out > everything he/she is typing. It doesn't > work if they are in raw mode. > > I don't know who wrote it. > ...stuff deleted... >Before I get mail asking me for copies of the software, let me >state my policy. I will not pass out stealbuf or eye to anybody. >Stealbuf doesn't work on BSD43 and eye only works on Suns. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >current version of eye is nothing but a machine cracker. I don't >see a reason to pass this around. > >-- >Josh Siegel (siegel@hc.dspo.gov) > Friends don't let Friends eat Cherry Zingers Not quite true. We have successfully modified our home-grown version of stealbuf to work on BSD4.3 (of course, I'm assuming that you can read /dev/kmem) ..bruce Bruce K. Martin Jr. UC. Davis Div of Computer Science martin@iris.ucdavis.edu --or-- {ucbvax | lll-crg}!ucdavis!iris!martin
jhc@mtune.ATT.COM (Jonathan Clark) (09/22/87)
>> /* output */ /* input */ >> mblk_t *dup; mblk_t *dup; >> dup = copymsg(mp); dup = copymsg(mp); >> putnext(up_to_monitor,dup); putnext(up_to_monitor,dup); >> putnext(down_to_device,mp); putnext(up_from_device,mp); > >this means that *everything* going up and down the stream gets sent upstream Well, the original requirement was that *everything* the user typed or was sent be seen on the monitoring terminal! >It's straightforward enough to duplicate only the interesting messages with >a switch statement, but it does increase the line count a bit more.... And I did mention that the 'guts' of the procedure could be done in three lines. Such trivialities as ensuring that the monitor tty is useable after unusual conditions are left as an exercise for the enthusiastic streams programmer :-) >I could imagine some packaged systems supplying a prebuilt kernel or kernels. I can imagine this as well although I understood that the SVR3 licence forbad this. I'm willing to be corrected by anyone who's actually seen one though. >Umm, no, it doesn't. I said "consist(s) *solely* of a user-mode program that >drops on top of a *non-hacked* UNIX system." You're right. I withdraw the comment. Although I personally believe that any streams modules *ought* to be user-level code, and that an experimental streams module shouldn't wreck the rest of the kernel when it falls over. Of course this would mean that you'd need more than two mutually protected address spaces. (Does this violate POSIX?) How about agreeing on 'come the revolution, this *will* be easy'? -- Jonathan Clark [NAC,attmail]!mtune!jhc The Englishman never enjoys himself except for some noble purpose.
guy%gorodish@Sun.COM (Guy Harris) (09/22/87)
> >this means that *everything* going up and down the stream gets sent upstream > > Well, the original requirement was that *everything* the user typed or > was sent be seen on the monitoring terminal! When I said *everything*, I meant *everything*, including e.g. "ioctl" messages. This was not part of the original requirement, and naively dumping the bytes of such a message on the monitoring terminal is not likely to be useful. If the person sitting at the monitoring terminal isn't familiar with UNIX systems calls, even dumping the "ioctl" information in a nice programmer-readable form isn't likely to be useful.... > >I could imagine some packaged systems supplying a prebuilt kernel or > >kernels. > > I can imagine this as well although I understood that the SVR3 licence > forbad this. If this is true, this would be an incredibly stupid move, as it would interfere with people using UNIX as e.g. a hidden component in an embedded system. > > >Umm, no, it doesn't. I said "consist(s) *solely* of a user-mode program > >that drops on top of a *non-hacked* UNIX system." > > You're right. I withdraw the comment. Although I personally believe that > any streams modules *ought* to be user-level code, and that an > experimental streams module shouldn't wreck the rest of the kernel when it > falls over. Of course this would mean that you'd need more than two > mutually protected address spaces. (Does this violate POSIX?) > > How about agreeing on 'come the revolution, this *will* be easy'? Yes, I agree on that one; were it possible to put large chunks of what is now kernel code into user mode (not just streams modules, but device drivers, file systems, etc., etc.), it would be a lot easier to add this sort of extension. Some people from Apollo gave a paper at the last Usenix on their user-mode streams implementation, which admittedly sits on top of something other than (and more modern than) a UNIX kernel. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
peter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <1431@cognos.UUCP>, brianc@cognos.uucp (Brian Campbell) writes: > ! <...an effective tty watcher or "spy" program, > ! <Looks like MS-DOS wins this round. > ! When did MS-DOS start supporting multiple users so that such a thing > ! would make sense? > Well, although the posted message didn't specifically mention it, the > original question related to watching what callers were doing on a BBS. > I guess MS-DOS just might have won this round. You can, of course, do the same thing on UNIX (watch what people are doing on a BBS), exactly the same way (have the BBS program echo stuff). I've seen two systems that do it (one of which not only traps the characters, but talks to called processes via pipes so you can have other programs do mail, etc, and have them echoed too). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
allbery@ncoast.UUCP (Brandon Allbery) (09/29/87)
As quoted from <28747@sun.uucp> by guy%gorodish@Sun.COM (Guy Harris): +--------------- | Yes, I agree on that one; were it possible to put large chunks of what is now | kernel code into user mode (not just streams modules, but device drivers, file | systems, etc., etc.), it would be a lot easier to add this sort of extension. | Some people from Apollo gave a paper at the last Usenix on their user-mode | streams implementation, which admittedly sits on top of something other than | (and more modern than) a UNIX kernel. +--------------- I don't believe it -- *Minix* wins this round!!! You see, the FS process, which implements the file system, *is* a user mode process. Yes, it is loaded with the kernel, but it doesn't have to be -- and in fact it can be run as a regular UNIX process with e.g. System V messages used for IPC in place of Minix messages. And people are working on network file systems which will be user-mode processes. Of course, it remains to integrate it into a useful OS. RMS, are you listening??? -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> "Mummy, what's an opinion?"
dhesi@bsu-cs.UUCP (09/30/87)
In article <4763@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >I don't believe it -- *Minix* wins this round!!! You see, the FS process, >which implements the file system, *is* a user mode process. Yes, it is >loaded with the kernel, but it doesn't have to be... Some clarification is needed here. By "user mode" do you mean "not a part of the kernel"? I don't think the 8086 CPU has a user mode and a privileged mode, so everything runs in user mode. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi