Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> writes:
> Don't configure syslogd to do reverse lookups.
Our syslogd has no option to disable the reverse lookups.
> You can NEVER guarantee that the reverse lookup will succeed, and
> can be delayed several minutes for a single reply.
Not true. The named on our loghost is authoritative for the reverse
mappings for all of the machines which can log there.
> I consider this a configuration error. I don't believe syslogd
> should ever do a reverse lookup, since the name you are trying to
> get may never arrive, or if arrives, it may be spoofed.
There *is* no configuration for these tools which gives the behavior
you describe, so this is not a "configuration error".
> It's not a bug, but a security feature. NO log to syslogd should be
> lost, since it may be related to an attack.
Historically, no other Unix system has had reliable syslogging. It
would require very defensive programming for syslogd, and that has
clearly not been performed.
And if this is what GNU/Linux intends, why does glibc use a SOCK_DGRAM
socket for communication with syslogd? By definition, such sockets
are *unreliable*. If syslog is supposed to be reliable, a different
connection type must be used.
Your philosophy that "no syslog message should ever be lost" is not
necessarily bad. But it is clearly at odds with historical practice,
the current glibc syslog() implementation, and the current syslogd
itself.
It is true that glibc falls back to using SOCK_STREAM if the
SOCK_DGRAM connection fails. Does that mean GNU/Linux is expects
syslog to be reliable eventually? If so, then my problem is entirely
a bug in syslogd and I will report it as such.
- Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:21 EST