Geoffm@AFSC-HQ.arpa (USAFA) (09/25/86)
I am interested in enhancing my UNIX system to support the following, but beofre I start to work I would like to know if anyone has already done something similar: 1. Modify CSH so that it checks for the existence of a system wide .cshrc and .login (obviously they could have different names) before reading the users .cshrc and .login. This would allow the system manager (me) to create a standard environment without having to write each user a .login and .cshrc and still allow the user to modify his or her environment if they choose. 2. Modify /etc/login so that it checks a file to determine if the user is allowed to login over that line or network connection or dial-up port at that time of the day. 3. And lastly modify the tty driver to support "advising." This would allow root to watch the characters sent to a terminal and have the characters that he types inserted into that port's input characte stream. Thanks, geoff -------
jrw@hropus.UUCP (Jim Webb) (09/28/86)
> I am interested in enhancing my UNIX system to support the following, but > beofre I start to work I would like to know if anyone has already done > something similar: > > 1. Modify CSH so that it checks for the existence of a system wide > .cshrc and .login (obviously they could have different names) before > reading the users .cshrc and .login. > > 2. Modify /etc/login so that it checks a file to determine if > the user is allowed to login over that line or network connection > or dial-up port at that time of the day. If you do 1. then you can add this to the system's .login to check the users and lines. > 3. And lastly modify the tty driver to support "advising." This would > allow root to watch the characters sent to a terminal and have the > characters that he types inserted into that port's input characte > stream. A hackers' delight, a simple rm -rf will remove this "advising" :-) -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw
guy@sun.uucp (Guy Harris) (09/29/86)
> > 2. Modify /etc/login so that it checks a file to determine if > > the user is allowed to login over that line or network connection > > or dial-up port at that time of the day. > > If you do 1. then you can add this to the system's .login to check > the users and lines. *And* to the system's .profile (i.e., "/etc/profile" if you have it), so that it also checks for Bourne and Korn shell users. Now you have something that works for Bourne, Korn, and C shell users. Your next mission, should you decide to accept it, is to make it work for all users whose login shell is a specific application; remember, those applications may not *have* the moral equivalent of "/etc/profile". Gee, it looks like you'll have to modify "/etc/login" after all.... -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
dave@sq.UUCP (10/02/86)
In article <702@hropus.UUCP> jrw@hropus.UUCP (Jim Webb) writes: >> 3. And lastly modify the tty driver to support "advising." This would >> allow root to watch the characters sent to a terminal and have the >> characters that he types inserted into that port's input character >> stream. > > A hackers' delight, a simple rm -rf will remove this "advising" :-) >-- >Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw A year or so ago a program called "force" was posted to net.sources. (Sorry but author and date elude me) This allowed for root to force characters, as if typed by the user, to a particular tty. --------------- David R. Seaman !utzoo!sq!dave SoftQuad Publishing Software
campbell@maynard.UUCP (Larry Campbell) (10/04/86)
In article <702@hropus.UUCP> jrw@hropus.UUCP (Jim Webb) writes: >> 3. And lastly modify the tty driver to support "advising." This would >> allow root to watch the characters sent to a terminal and have the >> characters that he types inserted into that port's input character >> stream. > > A hackers' delight, a simple rm -rf will remove this "advising" :-) Of course such a capability would be restricted to the root. One of TOPS-20s useful and, as far as I know, unique features is that of terminal "linking". The output queue for a terminal device may be "linked" to the output queues of up to four other terminal devices. When a link exists, all characters entered into the queue are also entered into the output queue of the other terminal(s). Whether a terminal can be linked to depends on a bit that the user controls; the default is to give permission. The commands ACCEPT LINKS and REFUSE LINKS control this bit. You would typically say REFUSE LINKS if you're typing out something confidential, or just don't want to be bothered by requests for help, etc. Of course, a privileged user can link regardless of the state of the permission bit. Most links are two-way, although a popular program called SPY allows a privileged user to spy silently on someone else's terminal session (very useful for catching system crackers in the act!). That's the output side. On the input side, the STI% (Simulate Terminal Input) system call allows a suitably privileged process to insert characters in the input stream of a terminal. This is used to implement the ADVISE command, which links two terminals, and copies all characters typed on the advisor's terminal to the advisee's terminal input stream. Of course, this requires privileges. It is very useful in demonstrating things to beginners. Demonstrating video editors and such requires that the two users be on similar terminals, but since most TOPS-20 users (and even most UNIX users?) are on VT100 compatible terminals, this isn't a problem in practice. -- Larry Campbell The Boston Software Works, Inc. ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109 UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
rbj@ICST-CMR.arpa (Root Boy Jim) (10/07/86)
> I am interested in enhancing my UNIX system to support the following, but > beofre I start to work I would like to know if anyone has already done > something similar: > > 1. Modify CSH so that it checks for the existence of a system wide > .cshrc and .login (obviously they could have different names) before > reading the users .cshrc and .login. This would allow the system > manager (me) to create a standard environment without having to write > each user a .login and .cshrc and still allow the user to modify his > or her environment if they choose. This should be easy enuf and I have no quarrel if done. One thing to watch out for: .cshrc is always executed when csh starts, while .login is only executed at login time. Do you want to implement both a pre-.cshrc and a pre-.login? If so, what will the sourcing order be? Would it be possible for the user's .cshrc to screw up the system version of .login? > 2. Modify /etc/login so that it checks a file to determine if > the user is allowed to login over that line or network connection > or dial-up port at that time of the day. Given the first modification, why bother. Just have the system startup file run an authorization program. If this guy is uncool, kill the parent csh. Before liberally proposing modifications to programs, one should think of other ways to achieve the same effect. > 3. And lastly modify the tty driver to support "advising." This would > allow root to watch the characters sent to a terminal and have the > characters that he types inserted into that port's input characte > stream. Nontrivial. > Thanks, > geoff (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> Hmmm... a PINHEAD, during an EARTHQUAKE, encounters an ALL-MIDGET FIDDLE ORCHESTRA...ha..ha..
brad@altunv.UUCP (Brad Silva) (10/07/86)
In article <1986Oct1.180413.29885@sq.uucp>, dave@sq.UUCP writes: > > In article <702@hropus.UUCP> jrw@hropus.UUCP (Jim Webb) writes: > >> 3. And lastly modify the tty driver to support "advising." This would > >> allow root to watch the characters sent to a terminal and have the > >> characters that he types inserted into that port's input character > >> stream. > > > > A hackers' delight, a simple rm -rf will remove this "advising" :-) > >-- > >Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw > > A year or so ago a program called "force" was posted to > net.sources. (Sorry but author and date elude me) > This allowed for root to force characters, as if typed > by the user, to a particular tty. > --------------- > David R. Seaman !utzoo!sq!dave SoftQuad Publishing Software If anybody has a copy of this program I would be greatly interested in it, or anything similar. I occasionally have to help users through problems, or do short training in various programs, and this would be VERY helpful. -- ---------------- Brad Silva "Seeker" ...!ptfsa!gilbbs!altunv!brad No disclaimer No cute joke No nothin' .... Yet! ---------------
chris@umcp-cs.UUCP (Chris Torek) (10/07/86)
In article <4119@brl-smoke.ARPA> Geoffm@AFSC-HQ.arpa (USAFA) writes: [wants to] >1. Modify CSH so that it checks for the existence of a system wide >.cshrc and .login (obviously they could have different names) before >reading the users .cshrc and .login. It would be far easier to create accounts with .cshrc and .login files that read source /usr/local/lib/cshrc and source /usr/local/lib/login This requires no source changes, which is a distinct advantage these days, what with upgrading from 4.2 to 4.3alpha to 4.3beta to 4.3beta++ to 4.3 to . . . ? >2. Modify /etc/login so that it checks a file to determine if >the user is allowed to login over that line or network connection >or dial-up port at that time of the day. This could be done without source changes by giving users special `shells' that do that check before switching to /bin/csh. We felt that login was important enough to hack, though; and Fred Blonder came up with a nice general mechanism which I will now advocate publicly: Whenever a user logs in, we look for a file with that user's name in the directory /etc/restrict/login. If the file exists, it is run. If it returns a successful exit code (0), the user may log in, otherwise not. These files are typically shell scripts, e.g.: # dcuug (D.C. Unix User's Group) login script if echo \^`tty`$ | grep -s -f /etc/restrict/dialups then if who | fgrep dcuug # | fgrep -s -f /etc/restrict/dialups then echo Sorry, but someone\'s already logged in to dcuug on echo one of our dial-in lines. Since we have few, we echo only allow one dcuug login from dialup at a time. echo exit 1 fi fi if /usr/local/bin/load -s 10 then echo Sorry, but the system load is too high to allow guests on. echo Please try back later. echo exit 1 fi exit 0 >3. And lastly modify the tty driver to support "advising." This is best done without modifying the kernel. In particular, it makes more sense to write a program that opens a pty and a socket, and listens to both. The pty acts as the user's terminal; the socket listens to the `administrator'. A separate program is run by the administrator; this can have whatever controls are desired to switch from `advising' mode to `commanding' mode or whatnot. (In fact, we have such a program, though I believe it is currently broken. We have a rather peculiar window system and window-based shell that supports `window cloning'. A cloned window copies whatever is done on the remote window. The other window need not be on the same machine, as the system uses Internet sockets. I would tell you who wrote it, but I think he is rather embarrassed at the internals, as he wrote this while simultaneously learning C, Unix, and networking. No doubt he would not want to distribute it in its current form. Nevertheless, it was indeed once working, and I think it provides a nice model.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
chris@umcp-cs.UUCP (Chris Torek) (10/07/86)
In article <359@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: [TOPS-20] >... On the input side, the STI% (Simulate Terminal Input) system >call allows a suitably privileged process to insert characters in >the input stream of a terminal. 4BSD has this; it is called TIOCSTI, Terminal I/O Control: Simulate Terminal Input. I think it is quite bogus myself. >This is used to implement the ADVISE command, which links two >terminals, and copies all characters typed on the advisor's terminal >to the advisee's terminal input stream. ... Demonstrating video >editors and such requires that the two users be on similar terminals, >but since most TOPS-20 users (and even most UNIX users?) are on >VT100 compatible terminals, this isn't a problem in practice. Speak for yourself! We have far too many thorougly incompatible terminals liberally sprinkled across the campus to do this. Fortunately, the cloning window shell I mentioned does not reqiure compatible terminals. Each window shell (possibly running on different machines) has its own notions about screen display. The editor is run in a window with an ANSI X3.64 virtual terminal emualtor, so that the cloned escape sequences invoke the same (virtual) functions, which are promptly implemented on the (phyiscal) screen using whatever escape sequences it requires. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
chris@umcp-cs.UUCP (Chris Torek) (10/07/86)
Whoops! In article <3714@umcp-cs.UUCP> I wrote: > # dcuug (D.C. Unix User's Group) login script > if > echo \^`tty`$ | grep -s -f /etc/restrict/dialups > then ... This, of course, does not work, since `-f' is an `fgrep' option, not a `grep' option. I did some surgery on the dcuug script, for I had noticed that it was rather wrong. Naturally, I did not test the result. This (also untested) should work rather better: if grep -s \^`tty`$ /etc/restrict/dialups; then ... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
jso@edison.UUCP (John Owens) (10/14/86)
In article <19@altunv.UUCP>, brad@altunv.UUCP (Brad Silva) writes: > In article <1986Oct1.180413.29885@sq.uucp>, dave@sq.UUCP writes: > > A year or so ago a program called "force" was posted to > > net.sources. (Sorry but author and date elude me) Well, I'm the original author, and here it is. (Of course it is possible that I never bothered to post it, and that someone else posted a similar program with the same name. Naahhh...) #include <sgtty.h> #include <stdio.h> main(argc,argv) char *argv[]; { char ch, *tty; static char ttyn[32] = "tty"; static char devn[32] = "/dev/"; int fd; struct sgttyb ttyb; char *strcat(); if (argc != 2) { fprintf(stderr,"Usage: force ttyname\n"); exit(1); } tty = argv[1]; if (*tty >= '0' && *tty <= '9') tty=strcat(ttyn,tty); if (*tty != '/') tty=strcat(devn,tty); fprintf(stderr,"force to %s:\n",tty); if ((fd=open(tty,2)) == -1) { fprintf(stderr,"force: Can't open %s\n",tty); exit(1); } gtty(0,&ttyb); ttyb.sg_flags |= RAW; stty(0,&ttyb); for (;;) { if (read(0,&ch,1) != 1) { fprintf(stderr,"read error\r\n"); break; } if (ch == 'P' - 0100) break; if (ioctl(fd,TIOCSTI,&ch)) { fprintf(stderr,"ioctl error\r\n"); break; } } ttyb.sg_flags &= ~RAW; stty(0,&ttyb); exit(0); } -- John Owens General Electric Company - Charlottesville, VA jso@edison.GE.COM old arpa: jso%edison.GE.COM@seismo.CSS.GOV +1 804 978 5726 old uucp: {seismo,decuac,houxm,calma}!edison!jso
kreek@rocky2.UUCP (Biochemical Endocrinology) (10/17/86)
In article <875@edison.UUCP>, jso@edison.UUCP (John Owens) writes: > > Well, I'm the original author, and here it is. (Of course it is > possible that I never bothered to post it, and that someone else > posted a similar program with the same name. Naahhh...) > > #include <sgtty.h> > #include <stdio.h> > > main(argc,argv) > char *argv[]; .... .... .... Question: What is this supposed to do? Thank you. -- UUCP: seismo| philabs| phri| -> cmcl2!rna!rocky2!kreek harvard| ihnp4| ARPANET: kreek@rockefeller.arpa BITNET: KREEK@ROCKVAX
mark@cogent.UUCP (Mark Steven Jeghers) (10/23/86)
In article <875@edison.UUCP> jso@edison.UUCP (John Owens) writes: >In article <19@altunv.UUCP>, brad@altunv.UUCP (Brad Silva) writes: >> In article <1986Oct1.180413.29885@sq.uucp>, dave@sq.UUCP writes: >> > A year or so ago a program called "force" was posted to >> > net.sources. (Sorry but author and date elude me) > >Well, I'm the original author, and here it is. (Of course it is >possible that I never bothered to post it, and that someone else >posted a similar program with the same name. Naahhh...) > I tried compiling force.c and got the following error: "force.c", line 39: TIOCSTI undefined Do I need to include some library or some such thing? -- +----------------------------------------------------------------------------+ | Mark Steven Jeghers - the living incarnation of "Deep-Thought" | | ("You won't like the answer ... you didn't ask it very well.") | | | | {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark | | ^^^^^^-------recommended------^^^^^ | | | | "A poodle-free world within a decade. We can do it...together!" | | | | Cogent Software Solutions can not be held responsible for anything said | | by the above person since they have no control over him in the first place | +----------------------------------------------------------------------------+
guy@sun.UUCP (10/23/86)
> I tried compiling force.c and got the following error: > > "force.c", line 39: TIOCSTI undefined > > Do I need to include some library or some such thing? No, you need to give up and build "force" only on machines whose operating system supports the operation needed for a process to be able to force characters to be "typed" on another terminal. TIOCSTI is an "ioctl" that takes a character and makes the terminal referred to by the file descriptor argument act as if that character had been typed on it. If you don't have this "ioctl", or something like it, you can't make "force" work. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)