Scott Long <scottl_at_FreeBSD.org> writes: > I understand and appreciate that. That's why I asked how other OS's > handle inetd. Ideally, the default configuration would limit the number of clients to some fixed figure, rather than limiting the number of connections. The latter is ineffective to control resource in the general case because it places no fixed upper limit and an attacker can run the machine out of file descriptors or memory. This is no news, Dan J. Bernstein, like him or not, has published this problem in 2000 at http://cr.yp.to/docs/inetd.html already. I'm not sure if this is a documentation issue or a configuration issue. I originally filed this in the "conf" category but it has one foot on the "docs" camp, too. On one hand, I'd say that setting inetd_enable=YES shouldn't cause DoS surprises, on the other hand I'm aware that there are so many options that have an impact on the choice which service should allow how many clients that it's impossible for the OS to offer a sensible default. DJB's tcpserver (not open source) uses a client limit of 40 unless otherwise configured, xinetd does not impose client limits by default but requires "instances=40" or similar configuration. The inetd shipping with SuSE Linux is outright crap of the old kind, allowing for 40 spawns per service per minute. In a previous discussion it was mentioned that changing the default might surprise users who run loaded services with many clients - so the last chance to make incompatible changes before 6 becomes "stable" is now. FreeBSD's inetd is among the better of its kind for its libwrap integration and absolute client limiting capabilities but the latter is not used in the default configuration but the unhelpful rate limiting. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)Received on Mon Sep 27 2004 - 21:07:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:14 UTC