kdq@demott.COM (Kevin D. Quitt) (03/10/90)
We have a modem on /dev/tty01 with a uugetty running on it for
normal network use. Occasionally, I would like to be able to use this
modem to call other systems (such as bbs's) and transfer files (we don't
have ftp capability). I have kermit to do the transfers, but it seems
to butt heads with the uugetty in trying to get the incoming data -
uugetty reads the output from kermit, barfs, sends error messages which
kermit gets as input.
Is there any way to make these guys happy campers? I hate to think
that this:
- modify /etc/inittab, changing respawn to off for /dev/tty01
- kill the uugetty
- use kermit
- modify /etc/inittab back to original
- kick init.
is the only "right" way to do things. What am I missing?
kdq
--
Kevin D. Quitt Manager, Software Development
DeMott Electronics Co. VOICE (818) 988-4975
14707 Keswick St. FAX (818) 997-1190
Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last
34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com
"Next time, Jack, write a God-damned memo!" - Jack Ryandold@mitisft.Convergent.COM (Clarence Dold) (03/11/90)
in article <62@demott.COM>, kdq@demott.COM (Kevin D. Quitt) says: > We have a modem on /dev/tty01 with a uugetty running on it for > have ftp capability). I have kermit to do the transfers, but it seems uugetty / kermit live happily on my machine. I recall that I had to change the 'locks' directory as defined in Kermit so that it agreed with the lock files that uugetty was adhering to. There was also a problem that kermit now had to be suid -> uucp, just like cu, however the standard kermit will fork a shell (! from the prompt) with the uid set to uucp, a little nasty, security wise. I think I fixed that with a setuid(getuid()), just before the fork/exec. System V R 3.2 eliminates that problem, as /bin/sh ignores setuid < 100. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 435-5293 ...pyramid!ctnews!tsmiti!dold FAX (408) 435-3105 P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007
pag@tcsc3b2.tcsc.com (Philip A. Gross) (03/13/90)
kdq@demott.COM (Kevin D. Quitt) writes: > We have a modem on /dev/tty01 with a uugetty running on it for >normal network use. Occasionally, I would like to be able to use this >modem to call other systems (such as bbs's) and transfer files (we don't >have ftp capability). I have kermit to do the transfers, but it seems >to butt heads with the uugetty in trying to get the incoming data - >uugetty reads the output from kermit, barfs, sends error messages which >kermit gets as input. > Is there any way to make these guys happy campers? I hate to think >that this: > - modify /etc/inittab, changing respawn to off for /dev/tty01 > - kill the uugetty > - use kermit > - modify /etc/inittab back to original > - kick init. >is the only "right" way to do things. What am I missing? >kdq >-- Well, I am going to guess that you might be using Un*x SVR3.2 or thereabouts. HoneyDanBer uucp uses the directory /usr/spool/locks to keep lock files regarding what devices are in use, etc. Many early versions of kermit may use the /usr/spool/uucp directory for these lock files. You basically need to modify kermit, if you have the sources, so that it uses the /usr/spool/locks directory instead. The HDB version of uugetty should then keep its mouth shut when kermit creates a lock file such as /usr/spool/locks/LCK..tty01. Hope this may point you in the proper direction. =============================================================================== Philip A. Gross The Computer Solution Co., Inc. Voice: 804-794-3491 ------------------------------------------------------------------------------- INTERNET: pag@tcsc3b2.tcsc.com USENET: ...!tcsc3b2!pag UUCP: tcsc3b2!pag (804)794-1514 ATTMAIL: attmail!tcsc3b2!pag ------------------------------------------------------------------------------- The opinions expressed here are strictly mine and nobody elses. << I haven't heard what I have to say about that yet. >> :-) -- =============================================================================== Philip A. Gross The Computer Solution Co., Inc. Voice: 804-794-3491 ------------------------------------------------------------------------------- INTERNET: pag@tcsc3b2.tcsc.com
rkh@mtune.ATT.COM (Robert Halloran) (03/14/90)
In article <1990Mar12.174721.13244@tcsc3b2.tcsc.com> pag@tcsc3b2.tcsc.com (Philip A. Gross) writes: >kdq@demott.COM (Kevin D. Quitt) writes: >> We have a modem on /dev/tty01 with a uugetty running on it for >>normal network use. Occasionally, I would like to be able to use this >>modem to call other systems (such as bbs's) and transfer files (we don't >>have ftp capability). I have kermit to do the transfers, but it seems >>to butt heads with the uugetty in trying to get the incoming data - > >Well, I am going to guess that you might be using Un*x SVR3.2 or >thereabouts. HoneyDanBer uucp uses the directory /usr/spool/locks >to keep lock files regarding what devices are in use, etc. The current versions of Unix kermit have a make for 'att3bx', which is used to get the right directory for setting up lockfiles. Bob Halloran ========================================================================= UUCP: att!mtune!rkh Internet: rkh@mtune.ATT.COM Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed. Quote: "Remember, kids, if some weirdo in a blue suit offers you some DOS, JUST SAY NO!!!"
kdq@demott.COM (Kevin D. Quitt) (03/16/90)
My thanks to the following for providing help. The solution to the
kermit vs. uugetty problem was two-fold: kermit has to put the lock
file in /usr/spool/locks (and therefore must run setuid to uucp), and
the contents of the lock file must be the pid in %10d\n format. This is
done automatically if ATT3BX is defined, so I added that definition to
my system's definition line in the makefile.
Of course, a lot is left to be desired in kermit's handling of the
lock file, like checking for staleness, and making sure that shelled
commands are setuid not to uucp, but rather to the user. My version is
4C(68), so maybe that all has been fixed.
Thank you:
Jay A. Konigsberg
Larry Jones
Glenn Theobald
Steve Ward
Jim Shaw
Richard Ohnemus
Philip A. Gross
Robert Halloran
kdq
--
Kevin D. Quitt Manager, Software Development
DeMott Electronics Co. VOICE (818) 988-4975
14707 Keswick St. FAX (818) 997-1190
Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last
34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com
"Next time, Jack, write a God-damned memo!" - Jack Ryan - Hunt for Red Oct.jc@minya.UUCP (John Chambers) (03/28/90)
> Well, I am going to guess that you might be using Un*x SVR3.2 or > thereabouts. HoneyDanBer uucp uses the directory /usr/spool/locks > to keep lock files regarding what devices are in use, etc. Many > early versions of kermit may use the /usr/spool/uucp directory > for these lock files. You basically need to modify kermit, if you > have the sources, so that it uses the /usr/spool/locks directory > instead. The HDB version of uugetty should then keep its mouth > shut when kermit creates a lock file such as > /usr/spool/locks/LCK..tty01. You also need to know that there are many versions of HDB UUCP around that have an undocumented restriction on the lockfiles: they must be exactly 11 bytes long. In fact, they must be of the format: fprintf(lkf,"%10d\n",getpid()); On systems whose UUCP has this restriction, the behavior when this rule is not followed is simple and quite nasty: the lockfile is silently deleted by whatever program notices it, and the program (uucico, uugetty, whoever) goes ahead and uses the port. I first noticed this by stumbing across it just as you might guess. As it happened, I had the UUCP source available; it was my one of my jobs to port it to the machine. I located the code that checked lockfiles and verified that it acted as I had surmised. I was duly grossed out, of course, and offered to correct what I viewed as a serious bug. Nope; my job was to port the code and get it running exactly like ATT thought it should run. It wasn't my job to make unapproved and nonstandard modifications. (I hope I'm not committing some serious criminal act by so divulging internal details that I learned by reading the proprietary code. ;-) -- John Chambers ...!{harvard,ima,mit-eddie}!minya!jc [Sorry, no clever saying today.]