Wietse Venema wrote:
[]
> Information in logfiles is provided by an untrusted source. It
> can be extremely dangerous. As a safety measure, Postfix logging
> always maps non-printable non-ASCII characters to ?, and always
> truncates text to a known length.
>
> By allowing raw data to be logged, you can't even trust the line
> boundaries in your logfile. Imagine if someone can insert newlines
> (or even carriage returns) in your logfile, or lines that begin
> with ~!command or other magic sequences that make xterms do weird
> things, and so on. Logfiles are dangerous.

Is there any syslogd that will NOT check data it receives and will
not handle unprintable chars? Most standard syslogds on many systems
comes from syslogd.c by Eric Stallman, I don't remember *for sure*
if the original version did some sanity checks, but later versions
did. FreeBSD syslogd will not allow any 8bit data in logs (replacing
such chars with \ooo sequences), linux standard syslogd converts
control characters only. There are other syslogds (syslog-ng etc)
that may use some different storage backends (e.g. an sql database -
rather strange way of storing logs but that's different question)
that aren't that dependant on control chars, line boundaries etc.

When syslogd converts non-printable chars to octal form, buffer
may be overflown and thus some (ending) part of a message may be
truncated. But this is just yet another reason to reorder some
messages (another reason is to make messages more easy to parse
by automated tools): place fixed part produced by postfix first,
and incoming data last.

Well, there are other systems with syslogds that does not sanitize
input (may be). But postfix is unable to help here: be it twice,
10 times more sane, there are other ways to harm syslog exists --
it's machine-wide service (in 99% cases), any account/process/etc
may write anything to system log using syslog's control socket.
Do a workaround for such system so ther "there will be no way to
blame postfix" isn't an argument here.

For now, postfix does lose useful information. Just yesterday
I was forced to *remove* a call to santitization routine in order
to see what (illegal, with 8bit russian chars) address was used
by one of our luser clients in order to tell him what was wrong
at his side (me bad, it was possible to use tcpdump for that, but
I didn't thought about tcpdump at that time and choosed a hard
way...;)

/mjt
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]