kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) (09/20/90)
Ok, I've seen this posted on and off for a few years now and I've neither heard nor seen any definitive responses to it. There's a program available for VMS that my managerial counterpart has great joy in showing off to me whenever he gets the chance -- it's called Watch. (It's also a part of the Snap package.) It, with a few privs, will let ya view a person's terminal as though you had the same one as him/her, and it'll also let you become interactive with it, as though it were them typing. Now, realize this is just for system admin purposes! (cough) Well, anyway, what's the deal? Has one ever been written for under Unix? (With the plethora of hackers [old definition, not vernacular] that have and are in the Unix world today, I'd be really surprised if it hadn't.) Ok, let's say it hasn't. Then how about what it'd take to write one? I can think of a little theory (sharing their device buffers, etc etc) but I can see that I'd probably know more internals (how oddly appropriate) than I would ever want to if I were to sit down and do this (preferably not alone). But that may not be that bad. Whatcha think? Brendan Kehoe | Soon: brendan@cs.widener.edu For now: kehoe@scotty.dccs.upenn.edu | Or: bkehoe@widener.bitnet Last resort: brendan.kehoe@cyber.widener.edu
karl@ficc.ferranti.com (Karl Lehenbauer) (09/21/90)
In article <29835@netnews.upenn.edu> kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) writes: > Well, anyway, what's the deal? Has one ever been written for under Unix? Lots of times. Thing is, the authors wisely do not distribute them widely because they (and we) don't *want* managers, syspriv weenies and control freaks to have it. It's sort of like nuclear nonproliferation. Plus people really hate to be spied on. (As to whether it's legitimate to spy or not, it's a question for another newsgroup -- in my opinion management should use normal management tools for determining whether or not you're working -- like if you're meeting your schedules, never in your office, etc.) Or should I have said "It figures that VMS would have this" to bait all the VMS weenies? Naah, that'd be too easy... -- -- uunet!ficc!karl "jackpot: you may have an unnecessary change record" uunet!sugar!karl -- v7 diff
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/21/90)
In article <29835@netnews.upenn.edu> kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) writes: > Well, anyway, what's the deal? Has one ever been written for under Unix? (With > the plethora of hackers [old definition, not vernacular] that have and are in > the Unix world today, I'd be really surprised if it hadn't.) It's pretty easy to do with my pty program. (What isn't? :-) ) A user runs his session through the following script, sessplex, rather than the usual sess: #!/bin/sh ( umask 077; touch /tmp/sessin.$$; touch /tmp/sessout.$$ ) ( tail -f /tmp/sessin.$$ &; cat -u ) \ | sess "$@" | tee /tmp/sessout.$$ rm /tmp/sessin.$$ /tmp/sessout.$$ Now anything written to /tmp/sessin.$$ will be used as input to the session. The sysadmin can join a session by typing (e.g.) % tail -f /tmp/sessout.19432 &; stty -echo; cat -u > /tmp/sessin.19432 Of course, this assumes user cooperation. UNIX provides so many ways to communicate with the rest of the world that a user can probably find *some* way to execute commands unobserved if he wants. On the other hand, the admin of a pty-based system can easily make sessplex the default. Note that pty is only for BSD variants at the moment. ---Dan
jak@sactoh0.SAC.CA.US (Jay A. Konigsberg) (09/24/90)
In article <29835@netnews.upenn.edu> kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) writes: >It, with a few privs, will let ya view a person's terminal as though you had >the same one as him/her, and it'll also let you become interactive with it, >as though it were them typing. > Now, realize this is just for system admin purposes! (cough) Generally, this would require a patch to the kernel. However, a simple way generally available only to administrators is to splice the cable leading to the terminal you want to monitor. This doesn't sound like its as versital as what you describe, but its universally available. -- ------------------------------------------------------------- Jay @ SAC-UNIX, Sacramento, Ca. UUCP=...pacbell!sactoh0!jak If something is worth doing, its worth doing correctly.
jbm@celebr.uucp (John B. Milton) (10/02/90)
In article <29835@netnews.upenn.edu> kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) writes: [stuff about VMS WATCH] > Well, anyway, what's the deal? Has one ever been written for under Unix? (With >the plethora of hackers [old definition, not vernacular] that have and are in >the Unix world today, I'd be really surprised if it hadn't.) > Ok, let's say it hasn't. Then how about what it'd take to write one? I can >think of a little theory (sharing their device buffers, etc etc) but I can see >that I'd probably know more internals (how oddly appropriate) than I would >ever want to if I were to sit down and do this (preferably not alone). But >that may not be that bad. > Whatcha think? Hmm. As far as I know, this has not been done for UNIX. This was available under TOPS/20, I think it was called ADVISE. I would very much shy away from trying to modify one driver to accomplish this. There are some ugly high level sorts of things (tee-ish) that might sort of work, but certainly not retroactively. I would think that the appropriate way to implement it would be with a STREAMS module. The monitor program would open the tty device of the person to be monitored/assisted. The monitor would then push a monitor module onto the device and communicate with the module through ioctl() calls. One problem is that the tty (pty, sxt) device would have to be a STREAMS device. The monitor program could put the input/output through the tty in a window, look into the envp of the process to get the TERM variable (or dynamically figure out the term type), blah blah. The rest is just window dressing. Adapting to stty modes and such could be partially done by the monitor module. In the absence of STREAMS, one might be able to do it with a line discepline (old STREAMS). John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
tli@phakt.usc.edu (Tony Li) (10/11/90)
In article <1990Oct2.022530.15042@celebr.uucp> jbm@celebr.uucp (John B. Milton) writes: Hmm. As far as I know, this has not been done for UNIX. This was available under TOPS/20, I think it was called ADVISE. Under Tops-20, the 'spy' program let you see output. 'advise' also let you put stuff in the input buffer. Last spring, my operating systems lab class did a basic implementation of this for SunOS 4.0. The basic idea was to create a new device which reached down into the bottom of the stream of the victim's terminal session and installed a hook there. Data was fed back through the new device. Needless to say, this is only one possible design for this facility. -- Tony Li - USC Computer Science Department Internet: tli@usc.edu Uucp: usc!tli Thus spake the master programmer: "A well written program is its own heaven; a poorly-written program its own hell."
ag@cbmvax.commodore.com (Keith Gabryelski) (10/13/90)
In article <1990Oct2.022530.15042@celebr.uucp> jbm@celebr.uucp (John B. Milton) writes: >In article <29835@netnews.upenn.edu> kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) writes: >[stuff about VMS WATCH] >> Well, anyway, what's the deal? Has one ever been written for under >>Unix? (With the plethora of hackers [old definition, not vernacular] >>that have and are in the Unix world today, I'd be really surprised >>if it hadn't.) Ok, let's say it hasn't. Then how about what it'd >>take to write one? I can think of a little theory (sharing their >>device buffers, etc etc) but I can see that I'd probably know more >>internals (how oddly appropriate) than I would ever want to if I >>were to sit down and do this (preferably not alone). But that may >>not be that bad. Whatcha think? > >Hmm. As far as I know, this has not been done for UNIX. This was >available under TOPS/20, I think it was called ADVISE. I, infact, wrote one last weekend. I will be posting it to alt.sources in a few days. In works under System V Release 4 STREAMS (and can be ported to earlier streams versions). >I would think that the appropriate way to implement it would be with >a STREAMS module. The monitor program would open the tty device of >the person to be monitored/assisted. The monitor would then push a >monitor module onto the device and communicate with the module >through ioctl() calls. One problem is that the tty (pty, sxt) device >would have to be a STREAMS device. The monitor program could put the >input/output through the tty in a window, look into the envp of the >process to get the TERM variable (or dynamically figure out the term >type), blah blah. The rest is just window dressing. Adapting to stty >modes and such could be partially done by the monitor module. Except for the TERM sillyness my advise programs does just this. Pax, Keith
ag@cbmvax.commodore.com (Keith Gabryelski) (10/18/90)
In article <15139@cbmvax.commodore.com> I wrote: >In article <1990Oct2.022530.15042@celebr.uucp> jbm@celebr.uucp >(John B. Milton) writes: >>Hmm. As far as I know, this has not been done for UNIX. This was >>available under TOPS/20, I think it was called ADVISE. > >I, infact, wrote one last weekend. I will be posting it to alt.sources >in a few days. It works under System V Release 4 STREAMS (and can be >ported to earlier streams versions). I posted advise to alt.sources yesterday. To accept advise attachments to your terminal, you type: $ advise -a # use `-d' to disallow advise attaches. To advise someone who has done the above, type: $ advise [username or ttyname] `advise -a' pushes the advise module on the advisee's tty stream (below ldterm) and sends down an ioctl allowing advise attaches. A would-be advisor (by typing `advise username') opens up /dev/advise and sends down an ioctl to attach to ``usernames's'' terminal. At this point, all messages that get to the advise module's write-put routine get copied to any advisor's that have attached. Any stream M_DATA messages sent down /dev/advise get put on the advisee's read side queue (just below ldterm) as if the advisee's driver had recevied them. Pax, Keith Ps, there is no way in hell you will get this code to work on non-stream based ttys sub-systems.