Hi, I recently sent a problem report to SuSE feedback and reported the second problem to the xinetd mailing list (I presume Mandrake have already reported #1), but haven't got a response from SuSE yet. I'm resending the information so no-one is trapped. In xinetd-2.1.8.8p3, at least as of SuSE Linux 7.0 (didn't check older or newer versions), there are two major problems with xinetd. 1. SECURITY: Mandrake issued a security advisory about the umask being initialized to 0, so some network daemons create world + group writable files. See http://www.securityfocus.com/advisories/3351 NOTE that daemons which don't set a proper umask need to be fixed in the first place, fixing xinetd is only a band-aid. (void)umask(022); or (void)umask(022 | umask(077)); Should be a standard initialization procedure in daemons or their startup scripts. NOTE also that the standard inetd doesn't touch umask at all, but inherits it from its sysvinit script. In contrast, xinetd kills the umask and sets it to 0, so this cannot be fixed in an init script. WORKAROUND: write a wrapper script around the actual network server that looks like this: #! /bin/sh umask 022 exec /path/to/real_server "$@" exit 127 2. RELIABILITY: A service "flags = NAMEINARGS" configuration is killed by the defaults {} section key word "enabled = <service>". Cause is a bug in sconf.h. This does not strike when using disabled or omitting these keywords. Resulting problem: when you're using server = /usr/sbin/tcpd and configure enabled keywords in the defaults section, tcpd will have its own path as argv[0] rather than the first component of server_args, thus it will go into a unterminated loop, exec'ing itself all over again, eating up kernel resources and pids and flooding away log files. WORKAROUND: 1. don't use enabled = keyword 2. to catch looping services, add this to the TOP of your /etc/hosts.allow: tcpd : ALL : twist echo "421 service is looping on tcpd, aborting." This is harmless as long as you have one tcpd start another one in a different path which should be pretty uncommon. Note both bugs also affect 2.1.8.9pre15. I have been told pre16 is due out soon. A patch which remedies these problems, please incorporate these into the xinetd RPMs and provide the updated packages through the standard mechanisms follows: --- xinetd-2.1.8.8p3/xinetd/sconf.h.fix Sat Dec 11 01:07:18 1999 +++ xinetd-2.1.8.8p3/xinetd/sconf.h Sun Jun 17 14:34:02 2001 @@ -185,9 +185,9 @@ #define SC_IS_SPECIAL( scp ) ( M_IS_SET( (scp)->sc_type, ST_SPECIAL ) ) #define SC_IS_UNLISTED( scp ) ( M_IS_SET( (scp)->sc_type, ST_UNLISTED ) ) #define SC_IS_INTERCEPTED( scp ) ( M_IS_SET( (scp)->sc_xflags, SF_INTERCEPT ) ) -#define SC_IS_DISABLED( scp ) ( M_IS_SET( (scp)->sc_xflags, ST_DISABLED ) ) -#define SC_DISABLE(scp) ( M_SET( (scp)->sc_xflags, ST_DISABLED ) ) -#define SC_ENABLE(scp) ( M_CLEAR( (scp)->sc_xflags, ST_DISABLED ) ) +#define SC_IS_DISABLED( scp ) ( M_IS_SET( (scp)->sc_type, ST_DISABLED ) ) +#define SC_DISABLE(scp) ( M_SET( (scp)->sc_type, ST_DISABLED ) ) +#define SC_ENABLE(scp) ( M_CLEAR( (scp)->sc_type, ST_DISABLED ) ) #define LOGS_USERID( scp, flags ) \ ( M_IS_SET( (scp)->flags, LO_USERID ) && SC_ACCEPTS_CONNECTIONS( scp ) ) --- xinetd-2.1.8.8p3/xinetd/init.c.fix Sun Jun 17 14:34:43 2001 +++ xinetd-2.1.8.8p3/xinetd/init.c Sun Jun 17 14:34:53 2001 @@ -210,7 +210,7 @@ "Initialization of %s facility failed. Exiting...", mp->name ) ; exit( 1 ) ; } - (void) umask( 0 ) ; + (void) umask( 022 ) ; } -- Matthias Andree