--------- Received message begins Here ---------
>
> 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.
If the server is sufficiently busy, the reply WILL be delayed. It can
even be on the same host, it just may not get around to a reply immediately.
Authority is not equivalent to reply. The advantage of local files is
that the reverse lookup doesn't depend on ANY outside agency.
> > 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".
I think it requires a recompile of the syslogd source to make that
change. I grant that there isn't a runtime option for it (I do think
there should be).
> > 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.
Some do, some don't - Cray systems will shut down if the audit daemon
disappears. Syslogd on Linux is providing the corresponding facility,
at the current time. Neither syslogd, nor audit daemon are reliable on
SGI systems, trusted solaris shuts down - I believe. The normal solaris
is unknown since I haven't had time to fully configure either it or the
audit daemon yet.
> 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.
I think that is a "don't care" option on AF_UNIX connections. Required
for semantic compatability, but not 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.
I think it is only reliable on the local host. If a remote syslog
facility is used, then it may be dropped if the input queue becomes too
long.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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:22 EST