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

[Andrea Campi]

On Sun, Oct 10, 2004 at 02:16:12PM +0400, Gleb Smirnoff wrote:
> Forget about UDP. syslog(3) logs to local syslogd. The latter may
> forward message to other machine via UDP, but this is out of
> scope of our discussion.

Uhm... right, I was confused and I apologize for that. I now see
that UDP has nothing to do with it; and an ENOBUFS situation is
probably as serious as you mention. This makes most of my
arguments somewhat bogus... But not totally:

> 1. Not forever.

You keep stating that, but you don't prove it.

> 2. This is design error if logging thread holds a mutex, that stops
> the application at all.

Probably, but POLA dictates that you shouldn't go out on a limb and
break applications that happened to get away with it.

> A> Above all however, how can you say "not forever"? What kind of guarantee
> A> do you see that the application will never succeed its send() call?
> A> Sure, statistically it will succeed, but that is not good enough.
> 
> It will wait until syslogd processes other messages on the queue.

... and the calling thread manages to get a timeslice (on a severely
overloaded machine as you say) before other threads bog it down again.

> A> Note that I'm not advocating that "since it can fail, don't bother
> A> retrying". The concept of trying again is fine--my only gripe is with
> A> retrying an unbounded number of times.
> 
> That means: "I'd suggest that we leave a possibility to lose messages.
> Let it be harder to DoS logging, but possible."

Exactly. My point being that a syslog DoS is orders of magnitude less
important *on a generic, out-of-the-box installation* that an application
DoS. More advanced, security-conscious installations can do what they want,
but the default should be fairer than that.

> A>  - syslog() and family are unreliable functions (to the extent that they
> A>    even return void;
> 
> POSIX specification
>   http://www.opengroup.org/onlinepubs/000095399/functions/syslog.html
> does not say anything about reliability.
> 
> However, one can understand words "The syslog() function shall send a
> message to an implementation-defined logging facility" as "message
> should be delivered to local logging facility".

Should is not MUST ;-)

> A>  - if the change stays, I think it should be documented in the syslog(3)
> A>    man page;
> 
> Agreed.

Thanks.

> A>  - I strongly object to MFC'ing it;
> A>  - look into a better way to accomplish the goal.
> 
> To continue argument, you need a test case, which shows that some test
> application works slower by an order of magnitude or even stops, when
> an attacker floods syslogd.

killall -STOP syslogd was mentioned in a later answer (although I do
agree that's a contrived example). Even worse, this probably means a
local user that is able to generate enough syslog calls to cause an
ENOBUFS condition can DoS the whole system. I imagine this can't be too
hard to do if the system has a serial console at 9600...

Sorry, I don't want to be disrespectful or anything but I have no interest
(nor time) in continuing this discussion as I feel we both explained our
points of view. However, I feel this is serious enough to bring it up
with so@; I'll submit to whatever they think of this.

Bye,
	Andrea

-- 
     The three Rs of Microsoft support: Retry, Reboot, Reinstall.