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 -------
guy@sun.uucp (Guy Harris) (09/26/86)
> 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. Yes, several people have done this to the C shell, most of them probably inspired by the similar feature in the S3/S5 Bourne shell; those versions of the Bourne shell read "/etc/profile" before they read ".profile". I don't know if any of them had a system-wide ".cshrc", but they all had system-wide ".login"s. The trouble is that several people have done this, all giving the file a different name. I think Plexus called it "/etc/cshlogin"; at CCI, I called it "/etc/login" (this won't work in System III, where the "login" program was moved to "/etc", but System V moved it back to "/bin"); you could also call it "/etc/.login", but that means "ls /etc" won't show it unless "ls" is showing "." files. Karl Kleinpaste at Bell Labs Columbus called it "/etc/csh.login", as his also had to run on System III. One S3/S5 Bourne shell feature used by "/etc/profile" is that in an interactive shell, "$0" refers to the argv[0] of the shell that is running, so that it can tell whether it was invoked as "-sh", "-rsh", "-su", or other. (The S5/S5 "login" doesn't do things like checking for mail, printing the message of the day, etc.; it leaves that up to "/etc/profile", or whatever your other login shells do.) In Karl's C shell, "$0" was the argv[0] of the shell for interactive shells. In order not to break existing scripts, "$?0" was true only for scripts, not for interactive shells. You out there, Karl? What ever happened with that version of the C shell? -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
rcodi@yabbie.rmit.oz (Ian Donaldson) (09/27/86)
In article <4120@brl-smoke.ARPA>, Geoffm@AFSC-HQ.arpa (USAFA) 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 characte > stream. Under 4.2, you could do this easily by having the user type: script /dev/ttyxx where ttyxx is the tty that you are logged onto. This would enable you to see what the user is doing. Funny things would happen of course if the user jumped into vi, and you had a different terminal type :-) You would have to modify script to do non-buffered writes if the file mentioned was a tty, otherwise you won't see things immediatly when the user types them (script uses fwrite(3) to write to the file, and stdio in all its wisdom doesn't determine optimial buffering for anything other than stdout when it first writes to it). You could say: if(isatty(fileno(fscript))) setbuf(fscript, NULL); or some such, after the fscript = fopen(...) line. As far as you typing input on his tty, it could be done on most versions of 4.2 and some versions of 4.1, but that is currently a security hole, and is best left alone (or even better: fixed) It is without saying that this is something that should be done ONLY with consent of the user. Ian Donaldson
karl@cbrma.UUCP (Karl Kleinpaste) (09/30/86)
guy@sun.uucp (Guy Harris) writes: >> 1. Modify CSH so that it checks for the existence of a system wide >> .cshrc and .login... > >Yes, several people have done this to the C shell... > >The trouble is that several people have done this, all giving the file >a different name. I think Plexus called it "/etc/cshlogin"; at CCI, I >called it "/etc/login" (this won't work in System III, where the "login" >program was moved to "/etc", but System V moved it back to "/bin"); you >could also call it "/etc/.login", but that means "ls /etc" won't show it >unless "ls" is showing "." files. Karl Kleinpaste at Bell Labs Columbus >called it "/etc/csh.login", as his also had to run on System III. > >One S3/S5 Bourne shell feature used by "/etc/profile" is that in an >interactive shell, "$0" refers to the argv[0] of the shell that is running, >so that it can tell whether it was invoked as "-sh", "-rsh", "-su", or >other. (The S5/S5 "login" doesn't do things like checking for mail, >printing the message of the day, etc.; it leaves that up to "/etc/profile", >or whatever your other login shells do.) In Karl's C shell, "$0" was the >argv[0] of the shell for interactive shells. In order not to break existing >scripts, "$?0" was true only for scripts, not for interactive shells. > >You out there, Karl? What ever happened with that version of the C shell? Yes, that csh is alive and well and runnning on a mess of SysIII/V machines around Columbus, including but not necessarily limited to cbrm[a-e], cbux[a-d], a small army of network-invisible 3B2s, 3B15s, and 3B20s, and I don't know where all else. A strange machine called cbsnsz, methinks. The SysV version has these hacks and a number of others, including job control emulation which I mentioned here once before. The 4BSD version with similar hacks runs on a number of local VAXen and Suns. It correctly identifies $0 no matter how it is invoked, but does in fact return True for $?0 only if invoked in a script - as Guy said, that keeps scripts from breaking, though the usage of $?0 in scripts is relatively rare. The modification for using a global .login-equivalent file is really, really trivial, done just before the user's own .cshrc and .login. At the point in main() (file sh.c), where there is a comment, "Set an exit here in case of an interrupt," there's an "if" for whether or not .cshrc and .login should be source'd. The relevant code in my sources inside the if then looks like #ifdef CSHLOGIN if (loginsh) srccat ("", CSHLOGIN); #endif CSHLOGIN and then #define CSHLOGIN somewhere appropriate. As Guy pointed out, picking a filename for it is a pain because no two people will do it the same, but I picked /etc/csh.login as a reasonable compromise. I was going to distribute diffs of my mods to 4.2BSD csh a while back but got stalled for silly administrivia reasons having to do with my employer (ahem), but perhaps I'll go off and do it anyway - it's not that big a deal overall. -- Karl Kleinpaste
zeta@runx.OZ (Nick Andrew) (09/30/86)
In Message-ID: <4120@brl-smoke.ARPA> Geoffm@AFSC-HQ.arpa (USAFA) writes: > I am interested in enhancing my UNIX system ... etc... > 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. Are you very worried about 1 block diskspace per user? Obviously not. Give each user a single-line .cshrc or .login, which simply sources your system-wide one. "source /etc/.syscshrc" or whatever. And if they decide they don't want a bar of your system-wide version, they can remove that line from the start. And if they don't even know of its existence, you still have a "master" one. You can find me at.... ACSnet: zeta@runx.oz UUCP: {seismo,hplabs,mcvax,ukc,nttlab}!munnari!runx.oz!zeta Fidonet: nick andrew@[155/213] @[155/201] [---watch this space---] Zeta: nick@zeta, (02) 627-4177, Zeta Rtrs. Mail: "Zeta Microcomputer Software", P.O Box 177, Riverstone NSW 2765 Aust. "If something I say offends you then I must have hit a bullseye"
bzs@BU-CS.BU.EDU (Barry Shein) (10/03/86)
Guy Harris writes... >The trouble is that several people have done this, all giving the file >a different name. (proceeds to list various names for the system-wide .login files for csh) And I gave it a different name! Anyhow, call it what you like, here's the change to the file sh.c, around line 332, 4.2bsd: [note: it's just the one srcunit() line that needs to be added] if (loginsh) { /* BZS - srcunit/open does enuf access checking. Source a global .login file if it exists. Cannot use srccat et al cause they demand we be the owner. */ srcunit(dmove(open("/usr/lib/.login",0),-1),0,0) ; /* end BZS */ srccat(value("home"), "/.login"); } -Barry Shein, Boston University
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..
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)
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