/dev/log does not seem to be being listened on by syslogd which started in the usual way from /etc/rc.d/init.d/syslog The socket is created, but trivial tests of socket use then fail, such as the following Perl script: #! /usr/bin/perl -w use strict; use Socket; socket(SOCK, PF_UNIX, SOCK_STREAM, 0) || die "socket: $!"; connect(SOCK, sockaddr_un('/dev/log')) || die "connect: $!"; The equivalent Python: #! env python import socket sock = socket.socket (socket.AF_UNIX, socket.SOCK_STREAM) sock.connect ('/dev/log') fails also, returning 'Connection refused' in the same way. Both these scripts work fine under RH 6.0. This issue prevents some subsystems (eg Zope) from logging in their normal fashion via /dev/log. Jonathan Marsden <jonathan>
This issue seems to be that syslogd changed to use DGRAM rather than STREAM sockets. Changing SOCK_STREAM to SOCK_DGRAM in both sample scripts results in scripts that work under RH 6.1, but fail under RH 6.0. So now the question becomes, is there a reasonable way to do this portably? In Python, using try: ... except: ... works, but seems ugly. Is there a better way? And was this change to a well-known interface (/dev/log) documented anywhere appropriately, other than in the bowels of the syslogd sources? Thanks, Jonathan <jonathan>
It was changed for security reasons. If you'd like to use portable code, you can use the native interfaces to syslog in both languages; use Sys.Syslog (you might need to add qw(:DEFAULT setlogsock) so you can tell it to use local unix sockets as opposed to inet...) and import syslog Both work fine on 6.1; I see no reason to think they wouldn't work fine on earlier releases as well.
> It was changed for security reasons. So this means that other RH 6.1 subsystems that use STREAM sockets will soon be releasing security fixes so they use DGRAM sockets instead? > If you'd like to use portable code, you can use the native > interfaces to syslog in both languages; No, that module is not available on all platforms, so importing it actually *breaks* portability! This is why that approach was not used in the first place. The main reason for coding a separate logging system is to ensure it can work under Linux (use /dev/log), Win NT (use UDP to port 514), or (other places) just write to a log file. But it seems extremely unfortunate to have to code separately for RH 6.0 and RH 6.1, which are minor variations on one version of one Linux distribution. If you are going to change known public interfaces such as /dev/log, especially in a minor revision update, not a new major rev, could I respectfully suggest that you at least actually document such changes clearly and visibly when the new revision (RH 6.1 in this case) is released? If the use of STREAM unix sockets is per se a security issue (I am unclear why this would be the case, but will accept your word on it), then it seems we are stuck with trying both STREAM and DGRAM socket types, and using whichever one lets us connect. Jonathan
Actually, this should be fixed across releases now, with the release of the sysklogd security errata for all releases. The security problem, as mentioned in the errata, is that the use of stream sockets allows a user to use up all the available sockets.