[16616] in Athena Bugs

home help back first fref pref prev next nref lref last post

sun 8.2.15: athena inetd environment lossage

daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Jan 18 05:05:54 1999

Date: Mon, 18 Jan 1999 05:05:50 -0500 (EST)
To: bugs@MIT.EDU
From: John Hawkinson <jhawk@MIT.EDU>

I noticed that telnetd on mary-kay-commandos was closing
connections immediately after openning them.

truss -f'ing inetd, I found:

18543:  setsockopt(4, 65535, 8192, 0xEFFFC1B4, 4)       = 0
18543:  fcntl(4, F_SETFL, 0x00000002)                   = 0
18543:  close(4)                                        = 0
18543:  sysinfo(SI_HOSTNAME, "mary-kay-commandos.mit.edu", 256) = 27
18543:  open("/etc/prelogin", O_RDONLY)                 Err#2 ENOENT
18543:  stat("/mit/jhawk/krb5.conf", 0xEFFFF058)        Err#2 ENOENT
18543:  stat("/mit/jhawk/krb5.conf", 0xEFFFF058)        Err#2 ENOENT
18543:  stat("/mit/jhawk/krb5.conf", 0xEFFFF058)        Err#2 ENOENT
18543:  stat("/mit/jhawk/krb5.conf", 0xEFFFEE70)        Err#2 ENOENT
18543:      Incurred fault #6, FLTBOUNDS  %pc = 0x00067058
18543:        siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
18543:      Received signal #11, SIGSEGV [default]
18543:        siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
18543:          *** process killed ***

it appears that some time ago I restarted the athena
inetd with my (jhawk's) environment:

ary-kay-commandos.mit.edu# /usr/ucb/ps auxwwe 18878
USER       PID %CPU %MEM   SZ  RSS TT       S    START  TIME COMMAND
root     18878  0.0  1.6 1608  984 ?        S   Dec 29  1:01 /etc/athena/inetd -n AMANPATH=/usr/local/man:/usr/athena/man:/usr/openwin/man:/usr/dt/man:/usr/man:/usr/dt/man:/usr/proc/man:/opt/SUNWrtvc/man APATH=/usr/local/bin:/srvd/patch:/usr/athena/bin:/bin/athena:/usr/openwin/bin:/usr/openwin/demo:/usr/bin:/usr/ccs/bin:/usr/andrew/bin:/usr/athena/etc:/usr/sbin:/sbin:/usr/ucb:/usr/dt/bin:/usr/proc/bin:/usr/multicast:/opt/SUNWrtvc/bin ATHENA_SYS=sun4x_56 CLASSPATH=/mit/jhawk/.interMute/classes.zip DISPLAY=:0.0 EDITOR=emacs FRAME_MSG=1 FRAME_MSG_VER=4 HOME=/mit/jhawk KRB5CCNAME=/tmp/krb5cc_ttyp0 KRB5_CONFIG=/mit/jhawk/krb5.conf KRBTKFILE=/tmp/tkt_ttyp0 MANPATH=/mit/jhawk/man:/usr/local/man:/usr/athena/man:/usr/openwin/man:/usr/dt/man:/usr/man:/usr/dt/man:/usr/proc/man:/opt/SUNWrtvc/man:/mit/emacs19/man:/mit/sipb/man:/mit/sipbnet/man:/mit/sipb/afsuser/man:/mit/crypto/man/man:/mit/net-tools/man:/mit/gnu/man:/mit/cygnus/man:/mit/mbone/man:/mit/watchmaker/man:/mit/outland/man:/mit!
/ops/man:/mit/consult/man:/mit/games/man NOMHNPROC=1 OPATH=/srvd/patch:/usr/athena/bin:/bin/athena:/usr/openwin/bin:/bin:/usr/ucb:/usr/sbin:/usr/andrew/bin:. OPENWINHOME=/usr/openwin PATH=/srvd/patch:/usr/athena/bin:/etc/athena:/usr/sbin:/sbin:/bin/athena:/usr/bin:/usr/ccs/bin:/usr/athena/etc:/usr/ucb:/usr/openwin/bin:/etc SHELL=/afs/sipb/project/tcsh/betatcsh TZ=US/Eastern USER=jhawk VISUAL=vi WGFILE=/tmp/wg.0WzbjY WWW_HOME=/afs/sipb/project/www/root/index.html XSESSION=18080 bindir=arch/sun4x_56/bin hosttype=sun4 TERM=xterm WINDOWID=12582925 LOGNAME=jhawk SHLVL=2 PWD=/mit/sipbzlog HOST=mary-kay-commandos.mit.edu HOSTTYPE=sun4 PS1=#
mary-kay-commandos.mit.edu# /usr/ucb/ps auxwwe 147
USER       PID %CPU %MEM   SZ  RSS TT       S    START  TIME COMMAND
root       147  0.0  1.2 1788  716 ?        S   Nov 28  0:00 /usr/sbin/inetd -s PATH=/usr/sbin:/usr/bin TZ=US/Eastern

Notice the system inetd has a much smaller environment ;-)
This problem goes away if I give the athena inetd a similar
small environment:

mary-kay-commandos.mit.edu# env - PATH=/usr/sbin:/usr/bin TZ=US/Eastern /etc/athena/inetd -n

So there's an easy workaround.
The problems would be helped somewhat if
/etc/init.d/athena allowed you to do things
like restart inetd. Or that if, when you pulled
the inetd restarting lines out of it, they worked ;-)

This argues in favor of a more modular init.d/athena, and
possibly having it run env.

Not sure if this is practical.

It also seems to be a bug that an unreadable KRB5_CONFIG causes
telnetd to SEGV. I seem to recall this coming up before with other k5
clients, so perhaps it's a generic library bug and maybe even fixed.
(I can't recall and am disinclined to go searching at the moment).

Hmm.

--jhawk


home help back first fref pref prev next nref lref last post