On Jan 25, 2005, at 17:44, Csillag Tamás wrote:

>>> Yes, it's dietlibc. Dietlibc executes code from the stack during
>>> system calls,
>>> afaict.
>>
>> Well, it's definitely dietlibc.  I compiled runit with glibc
>> (statically) and it works just fine.   Very strange.
> I got the same with grsecurity (www.grsecurity.org).
> Well it did not stated exactly in the log that the stack operation is 
> the
> cause of killing that process.
>
> It could happen for *all* dietlibc linked program.
> (I experienced in: runsv svlogd fnord tcpsvd ... )

Odd thing here is that I tried a few other apps that were 
dietlibc-compiled and didn't see a problem.

Hmmm... spoke too soon.  None of the services requiring tcpsvd were 
installed, so I tried with rsync and if I start supervise on those 
services, nothing happens.  But if "sh -x run" myself, I can see the 
services are starting.  Not sure if recompiling ipsvd without dietlibc 
will help, but it's something I'll have to try.

> In grsec I use the chpax utility to bypass this security checks on 
> these
> (and only these) programs.

Ouch.  Not a good solution.

> Maybe it is worth asking the author of dietlibc..
> http://www.fefe.de/dietlibc/

I have... and am in the middle of a conversation with him.  He's very 
interested in seeing this resolved.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}