Bug 6597 - syslogd does not accept connections to /dev/log
Summary: syslogd does not accept connections to /dev/log
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sysklogd
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-01 11:52 UTC by jonathan
Modified: 2014-03-17 02:10 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 1999-12-01 19:35:47 UTC
Embargoed:


Attachments (Terms of Use)

Description jonathan 1999-11-01 11:52:16 UTC
/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>

Comment 1 jonathan 1999-11-01 14:50:59 UTC
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>

Comment 2 Bill Nottingham 1999-11-01 16:07:59 UTC
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.

Comment 3 jonathan 1999-11-04 12:34:59 UTC
> 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

Comment 4 Bill Nottingham 1999-12-01 19:35:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.