syslog

[hobbit () avian org (*Hobbit*)]

I screwed around some with this in the 44BSD environment today, and so far
noted the following things:

syslog(3) has a buffer size of 2048 that it builds the message into, but
syslogd(8) has a maximum buffer size [MAXLINE] of 1024.  Great, huh?  What
were they thinking...

In the "may be obvious to some" department, but still worth pointing out to
would-be implementors of a better syslog(3): snprintf and vsnprintf apparently
return the length of what they WOULD have copied, REGARDLESS of a given
limiting length.  This is hinted at in the BSD manpage, although it also
misleadingly says "These functions return the number of characters printed" for
the entire class of 'em.  But for *nprintf, the data actually moved is properly
limited per the "cnt" argument, but a larger value can be returned.  So you
CANNOT rely on that return value to simply bump your buffer pointer.  If
there's any chance of it wandering past your buffer as a result, you have to
check it after every call to *nprintf.  Something like

        ret = snprintf (buf, x, "got %s", user_supplied_data);
        if (ret > x)
                ret = x;

The excessively complex [by its own admission!] innards of BSD vfprintf seem
to implement the limiting by fiddling around with stdio buffers instead of
actually counting bytes, so the final count is as though the whole string were
treated.  This is from a vfprintf.c whose sccsid claims to be "8.1 (Berkeley)
6/4/93", so maybe newer ones work differently.  This is the same one, of
course, that seems to coredump if you feed it too many arguments.

Needless to say, the stock BSD syslog() buffer construction relies on the
return value from sprintf() to fiddle its pointers.  Sigh...

My mistrust of this is expressed in /src/fixkits/Hsyslog.c here, a quick-and-
dirty in which not only is the buffer length-checked as it is built, but if
something tries to overrun it, a "[truncated]" indication is stuffed into the
end.  This is also for 44bsd only at the moment; I haven't looked at Perry's
patch yet and I have *no* clue where to start building a portable one for
systems that don't have a basic snprintf() to begin with.  [Does the Gnu stuff
include one, maybe?]

Sendmail 8.6.x appears to do some syslog length-checking before issuing the
call in some specific places, but it's not at all clear if all the right
places have this.  Better to just call a paranoid syslog().  A temporary
workaround might be to set the 7-bit option and hope that embedded machine
instructions need their high bits on??

Wu-ftpd limits command strings to 512 characters, which at first glance would
appear to make it safe for systems whose syslogs internally use 1024.  But
there are a few calls that have more than one reference to user-supplied
data, the sum of which along with the control string can, um, add up.  I also
ran across a similar problem with setproctitle() while testing this, so you
probably want to #undef SETPROCTITLE and forget about it for your next rebuild
of ftpd and other daemons that do similar fluff.

And that's only two out of a gazillion daemons that syslog() with reckless
abandon.  Boy howdy, we live in interesting times.

_H*