jimmy@gryphon.CTS.COM (Jim Gottlieb) (10/15/87)
As the (generous) 90-day warranty is about to expire, it is time to decide
whether I want to buy a maintenance contract on my 3B1. They're quoting me
$525/yr. for carry-in and $936 for in-home service on my 2 X 67. I'm
just curious what people have ended up spending when their systems broke.
AT&T quotes $2000 for a new disk drive (more than I paid for the whole
machine!), though I assume they are available for cheaper. Can I use any
of the drives I see advertised for MS-DOS (excuse my french) machines? I
am told that AT&T doesn't like to fix the motherboard, they prefer just to
swap it out. Are there non-AT&T places that will actually repair it?
I notice that the machine defaults to Eastern Time (i.e. incoming uucp
calls are logged in EDT, 'who' run from the login: prompt shows people's
login times in Eastern). Since not _every_ UNIX PC owner is in New Jersey,
is it possible to change this?
Does anyone have a good 'finger' program for Sys V? I could (and may)
write my own, but I'm basically lazy.
And finally, are there any programs out there to make files on the drive
contiguous, or do you just have to do a backup and reload everything?
Thanks a lot...
--------------------------------------------------------------------------
Jim Gottlieb "It's easier to apologize than to ask permission.
When in doubt, do it."--Grace Hopper, U.S. Navy, Ret.
ARPA: ucla-an!denwa!jimmy@ee.ucla.edu
UUCP: {ucbvax, cepu, ihnp4}!ucla-cs!ucla-an!denwa!jimmy
UUCP: {hplabs!hp-sdd, sdcsvax, nosc}!crash!gryphon!denwa!jimmy
MCI: 304-9271
Voice: (213) 824-5454ken@maxepr.UUCP (Ken Brassler) (10/16/87)
In article <1913@gryphon.CTS.COM> jimmy@denwa.UUCP (Jim Gottlieb) writes: >I notice that the machine defaults to Eastern Time (i.e. incoming uucp >calls are logged in EDT,... I believe this is a U*ix problem, rather than just a 3b1 problem, and stems from the fact that when uucico is used as a login shell, it does not inherit the environment variables exported by init(?) - in particular, TZ. Also, uucico doesn't read a .profile, where TZ could be set. A previous discussion in a different newsgroup offered the following fix: 1. /etc/TZ should contain a string describing your timezone. For the west coast, it would be "PST8PDT" (no quotes), where 8 is the number of hours separating PST from GMT. 2. Change the /etc/passwd entries for uucp & nuucp to point to a shell script, rather than uucico. I use /usr/lib/uucp/uushell. 3. Create /usr/lib/uucp/uushell containing the following: if [ \( -f /etc/TZ \) -a \( -r /etc/TZ \) ] then TZ=`cat /etc/TZ` export TZ fi exec /usr/lib/uucp/uucico $* This has cleared up the problem on my system for all log entries written by uucico and it's children (I don't know about 'who'). -- Ken Brassler {ihnp4|qantel|pyramid|lll-crg}!ptsfa!maxepr!ken ....ethos!gladys!ptsfa!maxepr!ken
andrew@teletron.UUCP (Andrew Scott) (10/20/87)
In article <1913@gryphon.CTS.COM> jimmy@denwa.UUCP (Jim Gottlieb) writes: >I notice that the machine defaults to Eastern Time (i.e. incoming uucp >calls are logged in EDT,... In article <487@maxepr.UUCP>, ken@maxepr.UUCP (Ken Brassler) writes: > A previous discussion in a different newsgroup offered the following > fix: > > 2. Change the /etc/passwd entries for uucp & nuucp to point to a > shell script, rather than uucico. I use /usr/lib/uucp/uushell. > > 3. Create /usr/lib/uucp/uushell containing the following: > > if [ \( -f /etc/TZ \) -a \( -r /etc/TZ \) ] > then > TZ=`cat /etc/TZ` > export TZ > fi > exec /usr/lib/uucp/uucico $* Using a shell script for a login is a *bad thing*. I was shown how this is a security hole by lyndon@ncc. I wrote the following short driver to uucico to solve the problem. Rename the present uucico as 'uucico.exec' and name the compiled version of this program 'uucico'. Andrew static char *environ[] = { "PATH=:/bin:/usr/bin", "HOME=/usr/spool/uucppublic", "TZ=MST7MDT", /* or whatever */ 0 }; /* ARGSUSED */ main(argc, argv) int argc; char **argv; { (void) execve("/usr/lib/uucp/uucico.exec", argv, environ); return (0); }
allbery@ncoast.UUCP (Phil Smith) (10/21/87)
As quoted from <1913@gryphon.CTS.COM> by jimmy@gryphon.CTS.COM (Jim Gottlieb): +--------------- | Does anyone have a good 'finger' program for Sys V? I could (and may) | write my own, but I'm basically lazy. +--------------- I'm still trying to get my "w" to work. However, for some reason the code I pulled from "fuser" in unix-pc.sources doesn't seem to work.... is there some fundamental difference between 3.5 and 3.51 that it breaks (assuming fuser was written for 3.5), or ??? -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery
richard@islenet.UUCP (Richard Foulk) (10/21/87)
> > Using a shell script for a login is a *bad thing*. I was shown how this is > a security hole by lyndon@ncc. I wrote the following short driver to uucico > to solve the problem. Rename the present uucico as 'uucico.exec' and name > the compiled version of this program 'uucico'. > uucico is called from other places besides login. Since it doesn't need to have the environment altered in those cases or expects to get it from elsewhere, it would probably be better to leave uucico intact and simply change the entries in the passwd file to call your setup program by name. > static char *environ[] = > { > "PATH=:/bin:/usr/bin", > "HOME=/usr/spool/uucppublic", > "TZ=MST7MDT", /* or whatever */ > 0 > }; uucico likes to have LOGNAME defined also. -- Richard Foulk ...{dual,vortex,ihnp4}!islenet!richard Honolulu, Hawaii
rjd@tiger.UUCP (10/21/87)
> [Shell script] > > if [ \( -f /etc/TZ \) -a \( -r /etc/TZ \) ] > > then > > TZ=`cat /etc/TZ` > > export TZ > > fi > > exec /usr/lib/uucp/uucico $* > > Using a shell script for a login is a *bad thing*. I was shown how this is > a security hole by lyndon@ncc. I wrote the following short driver to uucico > to solve the problem. Rename the present uucico as 'uucico.exec' and name > the compiled version of this program 'uucico'. I have heard this blanket statement about shell scripts being a security hole before, possibly from you, and fail to see how this one (above) can be such. I fancy myself very literate in Unix security and agree that, in general, shell scripts from inittab or suid-root scripts *might* have a hole (usually in the form of a command that has a shell escape) but I do not see the problem with the "if" statement, "cat" command, variable assignment, export statement, or exec function. As long as the shell script is only readable and writeable for the person to whom it was intended to serve and located in a "safe" directory, I see no problem. I do agree that the C-code is more elegant, but I would greatly appreciate a posting or e-mail showing the holes as you see them. Thanks, Randy Davis (ihnp4!)3b2fst!randy
andrew@teletron.UUCP (Andrew Scott) (10/23/87)
In a discussion about how to get uucico to recognize the TZ environment variable, the following shell script was suggested as a login script: >>> if [ \( -f /etc/TZ \) -a \( -r /etc/TZ \) ] >>> then >>> TZ=`cat /etc/TZ` >>> export TZ >>> fi >>> exec /usr/lib/uucp/uucico $* and then I wrote: >> Using a shell script for a login is a *bad thing*. I was shown how this is >> a security hole by lyndon@ncc. Quite graphically, I might add. I was warned about login scripts by Lyndon when I told him that I had "fixed" the TZ problem I previously had. Shortly after e-mailing him "why?", I got something like: Message from uucp (ph1) ... are you there? on my screen. He had logged in and obtained a shell before uucico was exec'ed. One reply was: > I have heard this blanket statement about shell scripts being a security > hole before, possibly from you, and fail to see how this one (above) can (no, not me) > be such. I fancy myself very literate in Unix security and agree that, > in general, shell scripts from inittab or suid-root scripts *might* have > a hole (usually in the form of a command that has a shell escape) but I > do not see the problem with the "if" statement, "cat" command, variable > assignment, export statement, or exec function. As long as the shell script ^^^^^^ this is the problem > is only readable and writeable for the person to whom it was intended to > serve and located in a "safe" directory, I see no problem. > I do agree that the C-code is more elegant, but I would greatly appreciate > a posting or e-mail showing the holes as you see them. > > Thanks, > > Randy Davis > (ihnp4!)3b2fst!randy Well, there is a shell parameter called IFS (internal field separator) which delimits tokens to sh. If you change IFS to also include 'p' (as well as space, tab and newline), the 'export' line becomes 'ex ort'. Presto, you are in the editor, from which you can do a shell escape. Now, this would only be a problem if a) you have anonymous uucp logins (no password protection), or b) someone who knew the password (by reading L.sys on the remote system) wanted to snoop around. As for being "very literate in Unix security", Lyndon mentioned that this was actually quite a common and old trick. I guess you're not literate enough... (Sorry if that sounds rude, but I don't profess to be any sort of Unix wizard, and very few people (Lyndon excepted :-) impress me that they should.) Andrew
guy%gorodish@Sun.COM (Guy Harris) (10/23/87)
> uucico is called from other places besides login. Since it doesn't need > to have the environment altered in those cases or expects to get it from > elsewhere, Not unless "uucico" gets TZ from elsewhere; if the user isn't running with TZ set to the time zone that any dial-out units you have are in, it most definitely *does* need to have the environment altered so that it can't be spoofed into making long distance calls during prime time. In general, the fact that "uucico" is run from a user's session does not mean that it wants to inherit any properties of that session, such as time zone, path, etc.. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
guy%gorodish@Sun.COM (Guy Harris) (10/24/87)
> Well, there is a shell parameter called IFS (internal field separator) which > delimits tokens to sh. If you change IFS to also include 'p' (as well as > space, tab and newline), the 'export' line becomes 'ex ort'. Presto, you > are in the editor, from which you can do a shell escape. The fix to this particular trick is to set IFS as the first thing your script does (no, an assignment that sets IFS doesn't depend on the setting of IFS; I didn't believe it until I tried it); while you're at it, make sure you set PATH right afterwards. For those of you not sure how you *can* set IFS as part of logging in, note that "login" in S5 takes a list of environment variable settings as optional arguments, and that "getty" will pass arguments of that sort to "login"; the only ones the manual page claims "login" *won't* change are PATH and SHELL. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
allbery@ncoast.UUCP (10/28/87)
As quoted from <144800006@tiger.UUCP> by rjd@tiger.UUCP: +--------------- | > [Shell script] | > Using a shell script for a login is a *bad thing*. I was shown how this is | > a security hole by lyndon@ncc. I wrote the following short driver to uucico | > to solve the problem. Rename the present uucico as 'uucico.exec' and name | > the compiled version of this program 'uucico'. | | I have heard this blanket statement about shell scripts being a security | hole before, possibly from you, and fail to see how this one (above) can | be such. I fancy myself very literate in Unix security and agree that, +--------------- This has been reproduced on ncoast. All you have to do is hit DEL at the right time in a login shell script and you get an interactive shell. (Of course, this hole is rather hard to exploit on a reasonably fast system, since the window can be closed immediately by putting a trap command as the first line of the script.) Fix: use a C program instead. Using a shell script as the login shell has another misfeature, although it's not likely to affect a UUCP login: "su" on the majority of systems I've used will NOT execute a shell script. (It looks like "login" uses execlp(), but "su" uses execl().) In summary: don't use shell scripts as login shells. -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {harvard!necntc,well!hoptoad,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery "Uncle _who_?" -- Lt. Worf ^^^^^^^^^^^^^ NOTE NEW PATH!