For a tcp/nowait connection, inetd invokes accept(2) for
each pending connection; this call returns a file descriptor
associated with the new connection.
Twelve years ago, code was added to inetd to detect "failing
servers". The heuristic that identifies a failing server is
one that has been invoked a large number of times over some
specified interval (e.g., more than 128 ftp services started
in 60 seconds may flag the ftp service as "failing"). These
compile-time constants vary depending on vendor.
The problem is that, when a failing server is detected, the
code neglects to close the file descriptor returned by the
accept(2).
Security-Implications:
I suppose someone with ample free time could orchestrate an
attack buy pummeling services until the inetd process finally
runs out of file descriptors thus rendering inetd useless to
any new connections that require a new descriptor.
PR: 7286
Reviewed by: phk
Submitted by: Jeff Forys <jeff@forys.cranbury.nj.us>
to attempt to unblock SIGCHLD, but we actually want to unignore SIGPIPE.
Obtained from: OpenBSD
Finished conversion from sigvec to sigaction (don't assume that sa_mask
is a scalar...). Didn't convert from sigblock to sigprocmask. Didn't
fix missing error checking for sigaction...
forks. Furthermore, invalid input for tcpmux does not lead to
an exiting inetd.
This patch is recommended for people running tcpmux (which is NOT
enabled by default)
server to bind to. This works until you send it a SIGHUP with a
new service defined ... the new service is bound to INADDR_ANY.
This patch fixes this bug (in both RELENG_2_2 and -current).
This is a 2.2 candidate..(i.e. pure bug fix)
Submitted by: Archie Cobbs (archie@whistle.com)
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
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.
