[12703] in bugtraq
Re: local users can panic linux kernel (was: SuSE syslogd
daemon@ATHENA.MIT.EDU (Savochkin Andrey Vladimirovich)
Tue Nov 23 14:22:05 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <19991123125806.A27064@castle.nmd.msu.ru>
Date: Tue, 23 Nov 1999 12:58:06 +0300
Reply-To: Savochkin Andrey Vladimirovich <saw@MSU.RU>
From: Savochkin Andrey Vladimirovich <saw@MSU.RU>
X-To: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <E11q14h-0004Ai-00@the-village.bc.nu>; from "Alan Cox" on Mon,
Nov 22, 1999 at 09:32:38PM
Alan,
On Mon, Nov 22, 1999 at 09:32:38PM +0000, Alan Cox wrote:
> > It isn't clear for me what can be done to protect the whole system inside
> > syslogd. Does anybody knows what SuSE really changed?
> > Their source package isn't very helpful.
>
> There were two notable problems
>
> 1. Syslogd defaulted to stream sockets which means you have resource
> control problems - in fact Dan Bernstein posted some very good stuff
> about that issue about a year ago
>
> 2. The client code decided it would be a good idea to wait - ie do a
> blocking connect. Unfortunate it someone ate all the syslog handles
>
> With a datagram system it comes down to losing messages under load. I think that
> is about as good as you can get.
Thank you for your points.
I think that replacing stream sockets by datagram is a step in a wrong
direction. Datagram sockets are not only unreliable by definition.
Their use makes completely impossible for applications to check if their
message has been properly logged or no. Stream sockets allows at least catch
some cases when the message is lost.
The fact that libc provides syslog functions that return only void makes
result checking not so easy. But people may have their own libraries for
system logging which don't suffer from the problem.
It's clear that there are some resource control problems with connection
oriented sockets. These resource control problems may block logging under
certain conditions. But I don't think that these problems are unsolvable.
As a first step we may consider creating several unix sockets for different
facilities and some access control.
So it looks wrong for me to refuse attempts to solve the problems, drop some
existing code, and finally stop at intrinsicly unreliable solution.
Best regards
Andrey V.
Savochkin
