[16984] in Athena Bugs
strange inetd behavior on public workstation
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Sun Aug 1 10:35:46 1999
Message-Id: <199908011435.KAA04053@mary-kay-commandos.mit.edu>
To: bugs@MIT.EDU
Date: Sun, 01 Aug 1999 10:35:38 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>
I noticed this morning a couple of cluster workstations,
m66-080-3 and m12-182-20, that were access_on. I investigated, thinking
they may have been compromised in some way. Running track didn't find
anything interesting, however.
There was one Athena and one vendor inetd running as there
should be, and all of the relevant services were listed as switched in
/etc/athena/inetd.conf, and there were no appropriate services listed in
/etc/inet/inetd.conf.
Running reactivate and access_off had no affect on the machine
being remotely accessible; neither did HUP'ing inetd or sending it a
SIGUSR2 directly. Greg hypothesized that running access_on and then
access_off would fix the problem, but it didn't. Rebooting m12-182-20
did fix the problem.
Potentially interesting truss output, courtesy of kcr:
M66-080-3.mit.edu# truss -p 497
poll(0xEFFFDA50, 17, -1) (sleeping...)
Received signal #17, SIGUSR2, in poll() [caught]
siginfo: SIGUSR2 pid=4255 uid=0
poll(0xEFFFDA50, 17, -1) Err#4 EINTR
setcontext(0xEFFFD818)
poll(0xEFFFDA50, 17, -1) (sleeping...)
the USR2 is me running access_off
on emacs, which does have working switched services:
poll(0xEFFFDA28, 11, -1) (sleeping...)
Received signal #17, SIGUSR2, in poll() [caught]
siginfo: SIGUSR2 pid=25050 uid=6667
poll(0xEFFFDA28, 11, -1) Err#4 EINTR
sigprocmask(SIG_BLOCK, 0x0002D3D4, 0xEFFFD610) = 0
close(3) = 0
close(4) = 0
close(5) = 0
close(6) = 0
sigprocmask(SIG_SETMASK, 0xEFFFD610, 0x00000000) = 0
setcontext(0xEFFFD6F8)
poll(0xEFFFDA28, 7, -1) (sleeping...)
Greg asked if we could look into what process had the listener
socket for port 23. As he guess, it was pid 497, which is the athena
inetd running on m66-080-3.
The inetd on the m66 machine is still allowing incoming
connections, but is now in a state where it accepts the connection and
then hangs forever, making any more remote debugging of this impossible.
I'm not completely certain what put it into this state.
Garry
