Subject: RE: [Syslog] #1 - RFC3164, was: Consensus?

From: "Rainer Gerhards" <[email-masked]>
Date: Sun, 27 Nov 2005 11:06:53 +0100

Darren,

> > #1 testing and code review has shown that there is no point
> >    in trying to preserve more than <PRI>; RFC 3164 provides
> >    a false impression of common behaviour.
> >  
> > This is controversal, but the facts are suggesting this is 
> the way it
> > is.
> > We should try to reach consensus on this.
> 
> A catch here is that extending the format to be:
> 
> <PRI>VERSION
> 
> may produce unexpected results with various syslog daemons.

Please let us know which actual syslog deamons you mean (at best with
platform and version information).

I would also appreciate if you could do a quick test with them and post
the results. If possible, please send two messages to them. One as such:

"<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on
/dev/pts/8"

the other one

"<148>1 2003-10-11T22:14:15.003Z mymachine.example.com su 4711 MSGID -
'su root' failed for lonvick on /dev/pts/9"

I would appreciate if you could let us know the resulting format both in
log files as well as when relaying.

Information about the extend of message distortion will probably help us
to determine the importance of this issue.

Many thanks,
Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Darren Reed <[email-masked]>
Date: Mon, 28 Nov 2005 07:23:08 +1100 (EST)

> Darren,
..
> to determine the importance of this issue.

Why not just read the source code ?

Also, read down and observe what ^ is used for.
This has been forgotten in RFC 3164...

printline()
{
..
        /* test for special codes */
        pri = DEFUPRI;
        p = msg;
        if (*p == '<') {
                pri = 0;
                while (isdigit(*++p))
                        pri = 10 * pri + (*p - '0');
                if (*p == '>')
                        ++p;
        }
        if (pri &~ (LOG_FACMASK|LOG_PRIMASK))
                pri = DEFUPRI;

        /* don't allow users to log kernel messages */
        if (LOG_FAC(pri) == LOG_KERN)
                pri = LOG_MAKEPRI(LOG_USER, LOG_PRI(pri));

        q = line;

        while ((c = *p++) != '\0' &&
            q < &line[sizeof(line) - 2]) {
                c &= 0177;
                if (iscntrl(c))
                        if (c == '\n')
                                *q++ = ' ';
                        else if (c == '\t')
                                *q++ = '\t';
                        else {
                                *q++ = '^';
                                *q++ = c ^ 0100;
                        }
                else
                        *q++ = c;
        }
        *q = '\0';
        
        logmsg(pri, line, hname, 0);
}

logmsg()
{
..
        msglen = strlen(msg); 
        if (msglen < 16 || msg[3] != ' ' || msg[6] != ' ' ||
            msg[9] != ':' || msg[12] != ':' || msg[15] != ' ')
                flags |= ADDDATE;
..
}

On top of this, source code exists to map LF to "\n" and use the
\377 format for non-ASCII characters.

It would seem to me that some of our issues have been "solved" by
some vendors that need to be wide-character set savvy...

Darren