Submitted by: Archie Cobbs (Archie@whistle.com)
Changes to allow inted to control the number of servers to
start on each service. This is a defence against a denial of service attack
in which the system is made unusable by
an external party. It also allows the behaviour of
small memory systems to be more accuratly predicted, by
bounding the extent to which processes can multiply.
Submitted by: archie@whistle.com
changes to allow inetd to bind to a single interface
for more complicated options see xinetd in ports.
Obtained from: whistle.com
This causes:
1: inetd to clear it's getlogin() name at startup (in case the sysadmin
logged in and su'ed to root and restarted inetd)
2: inetd to start each spawned process in it's own session.
3: inetd to call setlogin() on non-root processes (eg: uucp for uucico)
4: log failures more extensively
This means that root spawned processes from inetd remain responsible for
setting their login name if they change their uid. (eg: rshd, login, etc).
If they do not do so, it is safer for them to have no "login name" than a
wrong one (like "root") because the getlogin() system call is documented
as "secure" on 4.4BSD. inetd when started from /etc/rc would have no login
name anyway, so this isn't really a change - it's making it consistant with
the bootup state...
The setsid() change *may* cause something to break that is doing a setsid()
itself and checking the result - it will fail now because it's already been
done. The consensis seems to be that this is unlikely. David G. thinks
this is acceptable as it is cleaner from an architectural point of view.
