[Bug libc/963] New: syslog() does not always NL terminate messages

[Bug libc/963] New: syslog() does not always NL terminate messages

[bazsi at balabit dot hu]

The syslog() subroutines in libc support both SOCK_STREAM and SOCK_DGRAM sockets
to fire off messages to syslogd.

When SOCK_STREAM sockets are used (default in old syslogds and preferred in
syslog-ng) lines should always be terminated by some record terminator
character or otherwise the receiving end will have no means to reconstruct
line structure.

According to the man page for syslog() an NL character is automatically 
added to messages that miss one:

"... A trailing newline is added when needed."

This is however not true, unless LOG_PERROR is specified as well:


        ...
        /* Output to stderr if requested. */
        if (LogStat & LOG_PERROR) {
                struct iovec iov[2];
                register struct iovec *v = iov;

                v->iov_base = buf + msgoff;
                v->iov_len = bufsize - msgoff;
                /* Append a newline if necessary.  */
                if (buf[bufsize - 1] != '\n')
                  {
                    ++v;
                    v->iov_base = (char *) "\n";
                    v->iov_len = 1;
                  }
                (void)__writev(STDERR_FILENO, iov, v - iov + 1);
        }

When using SOCK_STREAM sockets with applications that do not properly terminate
their messages with NL, lines will be folded together by the system logging 
process.

The proper fix would be to move the check for NL out of the LOG_PERROR block
and always add the NL if it is not present.

-- 
           Summary: syslog() does not always NL terminate messages
           Product: glibc
           Version: 2.3.2
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: bazsi at balabit dot hu
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=963

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/963] syslog() does not always NL terminate messages

[gotom at debian dot or dot jp]

------- Additional Comments From gotom at debian dot or dot jp  2005-06-01 14:29 -------
Look down at the LOG_PERROR line:

        /* If we have a SOCK_STREAM connection, also send ASCII NUL as
           a record terminator.  */
        if (LogType == SOCK_STREAM)
          ++bufsize;

Note that according to SUS, syslog() "may" add NL character
"if needed", so adding NL is not duty from the standard: 
http://www.opengroup.org/onlinepubs/009695399/functions/syslog.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sources.redhat.com/bugzilla/show_bug.cgi?id=963

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/963] syslog() does not always NL terminate messages

[bazsi at balabit dot hu]

------- Additional Comments From bazsi at balabit dot hu  2005-06-01 15:14 -------
It does not matter whether it is NL or NUL character, syslog-ng accepts both.

The problem is that sometimes neither NL or NUL is present. For example, 
here is an strace dump of syslog-ng, reading sendmail logs, which is using 
the syslog functions from libc:

read(16, "<20>May 20 07:48:02 sendmail[16668]: j4KEkWOv016668: collect:
premature EOM: unexpected close", 2048) = 93

Notice no \0 or \n

Then the next read

read(16, "<21>May 20 07:48:02 sendmail[16668]: j4KEkWOv016668: collect:
unexpected close on connection from [61.43.165.161],
sender=<Hager@indiatimes.com>\0<22>May 20 07:48:02 sendmail[16668]:
j4KEkWOv016668: from=<Hager@indiatimes.com>, size=0, class=0, nrcpts=1,
proto=SMTP, daemon=MTA, relay=[61.43.165.161]\0", 1955) = 300

A more complete strace dump and the mailing list thread leading to this
bugreport can be found at:

https://lists.balabit.hu/pipermail/syslog-ng/2005-May/007474.html

As I see both sendmail process use the same pid and assuming sendmail is not
threaded (which I don't know for sure these days) I doubt the reason for 
the strace dump above would be caused by some kind of race condition at 
writing the same fd. (and judging the libc code this is protected by a mutex anyway)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW


http://sources.redhat.com/bugzilla/show_bug.cgi?id=963

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/963] syslog() does not always NL terminate messages

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-09-27 15:20 -------
> The problem is that sometimes neither NL or NUL is present. For example, 
> here is an strace dump of syslog-ng, reading sendmail logs, which is using 
> the syslog functions from libc:

I cannot see how this could happen if the programs really use the libc syslog. 
We always send the NUL byte if the syslog socket is connected to a TCP server.

Provide a test case.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=963

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/963] syslog() does not always NL terminate messages

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-10-16 07:56 -------
Reopen if you have a test case.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=963

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.