Re: sudden (and selective) autism
At 14:26 Uhr -0700 19.04.2003, Jim McCloskey wrote:
A little net searching revealed that this problem can be caused when a
user with non-root privileges (re)starts the inetd daemon;
It's not possible for a normal user to stop an already running inetd
which was started by root. It *is* possible for any user to *start* a
(second) inetd, and sure that one will have a problem when trying to
bind to ports <1024 because that's reserved to the root user.
The more important question is why did the original inetd (started by
root) exit. (And sure, who did start the new one)
but the
output of `last' suggests that nobody was logged in to the system at
the point at which the problems first arose.
Somebody getting access to the server is not necessarily logged in
the wtmp database.
If inetd hat a buffer overflow problem, and someone made it crash,
and then (maybe later on) gained access to some user on the system
and restarted inetd, this could explain your observations. There are
no other explanations coming to my mind (netkit-inetd is not even
restarted by cron as it seems; the only other things killing a
running inetd should be software upgrades (of netkit-inetd), or maybe
some erroneous kill command issued by the admin).
Also: is it really
possible for a non-root user to start a system daemon?
Yes, try it out. He of course cannot stop an already running inetd
which was started by root.
The permissions
on /etc/init.d/inetd suggest that it should indeed be possible:
Even if those permissions where different, he could always start
/usr/sbin/inetd directly, or start an own inetd(-like) process.
There's nothing wrong with that.
-rwxr-xr-x 1 root root 1764 Nov 18 2001 inetd
But why is it necessary to give this permission to users in general?
It would not make sense to change that. There are other things that
determine whether a user may run some service, like permissions on
/var/run/, device files and ports.
Christian
Reply to: