working on a new syslogd.

[Darren Reed <avalon () coombs anu edu au>]

Over the past few months, I've spent some time (increasingly less
recently:-() on writing a new syslogd.  I'm at a point where I've
made a large amount of progress but before committing to doing things
the way they are, I'd like to invite others to review it.

The basis for this rewrite is that the current one (even with hacks
in freebsd, openbsd, and elsewhere) is not really able to deliver
what we need today - especially in firewalls.

One of the features I'd like to add, but am in a dither about how to
finalise, is adding a hash log for checking the current log file against
to detect unachanges (not prevent them).  This is all well and good,
except that the interaction over TCP for remote logging needs more work
for setting up the connection, ensuring both ends are using the same
hash algorithms, etc.  At this point, one might assume the position of
not worrying about this and implement something just for syslogd, but
I don't see that as being a win in the long run.  I should add that at
least one implementation of this technology is patent pending (see
Schneier's paper from Usenix Security '98).

A goal here has been to avoid crypto. (not worried if message contents
are secret or not as integrity is what's important) so that silly
governments don't need to worry about whether this is going in or out
of their countries.

I was hoping to have cleaned up the code a bit more before sending a
public email, but that was not to be.  Anyway, if you'd like to peruse
the source code, it can be retrieved from:

ftp://coombs.anu.edu.au/pub/net/misc/nsyslogd.tar.gz

A brief on some of the changes is included below.

Cheers,
Darren

New Syslogd.
------------

This new "syslogd" has been built to recognise the old format syslog.conf
files as well as a new format.  The new format has 5 basic lines:
- comment
- source specification
- filter specification
- destination specification
- log specification

This implementation of syslogd uses the following paradigm:

a message will arrive from a source, may be put through a number of various
filters and will be delivered to a destination.  The filtering selects 
whether or not to let the message proceed to be delivered.

Comments are marked by the #.

A source is defined thus:

        source src { file /dev/klog; unix /dev/log; udp 0.0.0.0,514; };

This defines a single source of messages "src" to consist of three parts:
a file named /dev/klog, a unix domain socket /dev/log and a UDP port at
port number 514.  Any syslog message detected on one of those sources is
considered to be coming from "src".  It is possible to use the same source
of messages, more than once, in a single configuration.  Thus you might
have:

        source src { file /dev/klog; unix /dev/log; udp 0.0.0.0,514; };
        source skern { file /dev/klog; };

where src groups a message as being from any one of its 3 constituents and
skern only cares about messages from /dev/klog.  For those who are concerned,
each is only opened once and common references are made.

Likewise, filters and destinations can be setup with common parts or each
being distinct on its own.  This document doesn't attempt to (yet anyway)
describe all the available options.

In specifying a log action, at least a source and destination may be
givern and optionally, one or more filters.  Thus if I had:
        destniation klog { file /var/log/kern; };
        log { source skern; destination klog; };
in combination with the above examples, all messages from /dev/klog would
get logged to /var/log/kern regardless of their content/priority/facility.
If we wanted to log all errors to /var/adm/messages, we might use the
above with:

        destination errs { file /var/log/messages; };
        filter errors { priority err; };
        log { source src; filter errors; destination errs; };

If I also wanted to *include* all authentication syslog messages in the
file errs, I might use:

        filter authm { facility auth; };
        log { source src; filter errors; filter authm; destination errs; };

but if I was only interested in auth messages from login, I might have:

        filter login { match-prog login; };
        log { source src; filter errors; filter authm,login;
                destination errs; };

or as:

        filter authm { facility auth; match-prog login; };
        log { source src; filter errors; filter authm; destination errs; };

For destinations which are files, it is possible to adjust the sync rate
at which fsync() is called.  By changing errs to the below, it will call
fsync() after every thirthieth message has been save to /var/log/messages:

        destination errs { file /var/log/messages; sync 30; };