cvs commit: src/lib/libc/gen syslog.c

[Gleb Smirnoff]

On Sun, Oct 10, 2004 at 12:08:42PM +0100, David Malone wrote:
D> > 1. Not forever.
D> 
D> If syslogd has hung (as opposed to being busy), it will wait forever.
D> Try "killall -STOP syslogd" and then logging a bundle of messages.
D> With the old situation other services continue to run, with the new
D> situation every program that calls syslog(3) end up stuck.

Yes, after this change interface is less antifootshooting. But you
shouldn't do "killall -STOP syslogd", as well as you shouldn't do
"killall -STOP sshd".

D> > 3. If /var/run/log is overflowed that means that your machine is already
D> > slowed down by syslogd process and its IO. Your application is already
D> > not doing its best.
D> 
D> > Better have consistent logs later to investigate that DoS. An attacker
D> > may trigger that DoS intentionally to hide some messages, which will
D> > be logged if syslogd is not overflowed.
D> 
D> This can happen in situations other than DoSs. Previously there
D> have been situations where syslogd hangs if a serial console becomes
D> confused or because of a coding error. This change makes it impossible
D> to su and fix the problem. IMHO, this is worse than loosing syslog
D> messages.

Then we should correct these coding errors if they exist.

D> (I guess if someone can log enough messages to the syslog socket
D> to cause ENOBUFS, they can also log enough messages to fill up /var
D> and have syslogd stop logging because the disk is full.)

It is much easier to trigger ENOBUFS condition. And syslogd may
write logs to multiple destinations, not only /var. If /var has enough
free space to survive for 5 minutes, than newsyslog will save space on
next run.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE