sudden (and selective) autism
A small server that has served 4 or 5 users faithfully and without
problems for nearly 4 months:
11:04:36 up 118 days, 18:50, 1 user, load average: 0.00, 0.00, 0.00
suddenly started refusing net connections at 14:17 on Friday
afternoon. The system runs Debian stable and the kernel is a
hand-compiled version of 2.4.18.
A little checking quickly revealed that the connection requests that
were being refused were all and only those dealt with by services
started by inetd---in this case sendfile/saft, vsftp, and mail. SSh
continued to work fine for both inbound and outbound connections.
The file /etc/inetd.conf seemed unchanged, but the logs had this at 10
minute intervals:
Apr 18 14:17:12 localhost inetd[944]: daytime/tcp: bind: Permission denied
Apr 18 14:17:12 localhost inetd[944]: time/tcp: bind: Permission denied
Apr 18 14:17:12 localhost inetd[944]: ftp/tcp: bind: Permission denied
Apr 18 14:17:12 localhost inetd[944]: smtp/tcp: bind: Permission denied
Apr 18 14:17:12 localhost inetd[944]: saft/tcp: bind: Permission denied
Apr 18 14:27:12 localhost inetd[944]: saft/tcp: bind: Permission denied
Apr 18 14:27:12 localhost inetd[944]: smtp/tcp: bind: Permission denied
Apr 18 14:27:12 localhost inetd[944]: ftp/tcp: bind: Permission denied
Apr 18 14:27:12 localhost inetd[944]: time/tcp: bind: Permission denied
Apr 18 14:27:12 localhost inetd[944]: daytime/tcp: bind: Permission denied
Restarting inetd did not fix the problem. Bringing down and bringing
up the network interfaces didn't fix the problem. Rebooting did.
All seems fine now, but of course I'm worried because I don't know
what happened or what it might mean.
A little net searching revealed that this problem can be caused when a
user with non-root privileges (re)starts the inetd daemon; but the
output of `last' suggests that nobody was logged in to the system at
the point at which the problems first arose. Also: is it really
possible for a non-root user to start a system daemon? The permissions
on /etc/init.d/inetd suggest that it should indeed be possible:
-rwxr-xr-x 1 root root 1764 Nov 18 2001 inetd
But why is it necessary to give this permission to users in general?
If anyone could shed any further light on this episode, or suggest
precautions that might prevent it happening again, I'd be most
grateful.
Jim
Reply to: