Subject: bug in the new sysklogd package in slackware-current? (fwd)
From: Hank Leininger (hlein@progressive-comp.com)
Date: Mon Sep 25 2000 - 18:51:15 CEST
[ sysklogd@infodrom.north.de added to the cc list after determining that
a bug in slackware-current is in fact a bug in sysklogd 1.4... ]
I haven't heard anything since sending this, but here's an update (a
fix, whee). This patch against the sysklogd-1.4 available at
ftp://ftp.slackware.com/pub/slackware/slackware-current/source/a/sysklogd/
...fixes the problem.
--- syslog.c.orig Sat Aug 21 06:28:44 1999
+++ syslog.c Mon Sep 25 10:34:38 2000
@@ -208,7 +208,7 @@
strncpy(SyslogAddr.sa_data, _PATH_LOGNAME,
sizeof(SyslogAddr.sa_data));
if (LogStat & LOG_NDELAY) {
- LogFile = socket(AF_UNIX, SOCK_STREAM, 0);
+ LogFile = socket(AF_UNIX, SOCK_DGRAM, 0);
/* fcntl(LogFile, F_SETFD, 1); */
}
}
This bug is indeed inherited from the standard 1.4 release. Ah, I see
where this crept in. Olaf Kirch/Suse has had SOCK_DGRAM patches for
syslogd for some time, that work. But, when he posted an updated patch
for a 1.4 release candidate, the patchlet above for syslog.c somehow got
missed:
http://marc.theaimsgroup.com/?l=sysklogd&m=96989685607949&w=2
And that patch was rolled in despite Solar Designer pointing out the
syslog.c problem:
http://marc.theaimsgroup.com/?l=sysklogd&m=96989685607952&w=2
From the looks of it, only Slackware and Caldera have yet rolled out
1.4-based sysklogd's, and Caldera has silently fixed this bug.
As far as these changes also breaking libc5 apps syslogging... short of
creating a new libc.so.5.x.x, an LD_PRELOAD'able libc5-compatible .so
that overloads syslog(3) and/or openlog(3) would work, but be
cumbersome. Is there Magic Loader Goo that could be used have the
overloading done automagically by ld.so for libc5 binaries? Of course,
neither of these do diddly for statically-linked libc5 bins...
Hank Leininger <hlein@progressive-comp.com>
---------- Forwarded message ----------
Date: Wed, 20 Sep 2000 18:33:44 -0400 (EDT)
From: Hank Leininger <hlein@progressive-comp.com>
To: Slackware Security Team <security@slackware.com>
Cc: Joe Segreti <seg@uidzero.clark.net>
Subject: bug in the new sysklogd package in slackware-current?
With the 1.4 sysklogd in -current applied to a 7.0 box, klogd fails to
forward kernel messages to syslogd; a friend is having the same problem
on 7.1 w/patched sysklogd (both boxes running glibc-2.1.3 from -current,
and 2.2.16+solard's OpenWall and my HAP patches, FWIW). Basically,
klogd gets 'ECONNREFUSED' when trying to connect to /dev/log (and
blunders on anyway), and ENOTCONN when trying to write. Other writers
to syslog via /dev/log -- sendmail, logger, etc -- seem to be fine.
I haven't pulled the current sources yet, but looking at straces I
think I've figured out what's happening. syslogd creates the /dev/log
socket as a SOCK_DGRAM:
[pid 1959] unlink("/dev/log") = -1 ENOENT (No such file or directory)
[pid 1959] socket(PF_UNIX, SOCK_DGRAM, 0) = 0
[pid 1959] bind(0, {sun_family=AF_UNIX, sun_path="/dev/log"}, 10) = 0
[pid 1959] chmod("/dev/log", 0666) = 0
...while klogd tries to connect from a socket type SOCK_STREAM:
socket(PF_UNIX, SOCK_STREAM, 0) = 1
connect(1, {sun_family=AF_UNIX, sun_path="/dev/log"}, 10) = -1 \
ECONNREFUSED (Connection refused)
[snip]
write(1, "<6>Sep 20 18:15:29 kernel: klogd"..., 73) = -1 ENOTCONN \
(Transport end point is not connected)
...It seems that all(?) other apps calling syslog() either use
SOCK_DGRAM by default, and/or are smart enough to try alternates if the
first method fails; probably glibc's syslog(3) and openlog(3) do this
transparently, and klogd doesn't use syslog(3) but writes to /dev/log
directly?
Anyway, it looks as if syslogd has switched from STREAM to DGRAM,
because of the DoS potential for SOCK_STREAM (see the Bugtraq threads:
http://marc.theaimsgroup.com/?l=bugtraq&r=1&s=sysklogd+dos&q=b ) but
klogd hasn't been appropriately updated ;)
Hank Leininger <hlein@progressive-comp.com>
This archive was generated by hypermail 2b25 : Mon Sep 25 2000 - 18:52:15 CEST