Re: [gentoo-hardened] what RLIMIT_STACK mean?

["Javier Martínez" <tazok.id0@gmail.com>]

PD: to see why the stack growth so much you can only pass  gdb to the
binary itself, as you can suppose I can't know why it happens to you.

2008/9/29 Javier Martínez <tazok.id0@gmail.com>:
> As I said it seems to be a problem with the rlimits, maybe
> CAP_SYS_RESOURCE privilege is not granted to the binaries affected, or
> you have problems with ulimit as I said. You can strace the binary to
> see what it does and the error code, and with a more deep knowledge of
> the problem to solve it.
>
> 2008/9/29 Alex Efros <powerman@powerman.asdfgroup.com>:
>> Hi!
>>
>> On Mon, Sep 29, 2008 at 05:46:28PM +0200, Javier Mart?nez wrote:
>>> I think it's not a good idea to do what you have done, people answers
>>> questions if they know the answer and they want to do it (and have
>>> time to do so). Please think that you didn't pay anybody to demand
>>> nothing.
>>
>> I understand, but I don't think something was wrong in this case.
>>
>> At first, I don't just "demand answers", I also spend my own time
>> contributing to community - answer questions in different maillists,
>> submit to bugzilla, etc. And have enough free soft and documentation on my
>> home website.
>>
>> At second, I don't just "refresh" that thread, but add new information
>> about topic which may be important for people who trying to find answer or
>> for people who will search this maillist later looking for same issue.
>>
>>> I don't use grsecurity but it seems that cat needs to growth their
>>> stack over the hard limit imposed (look for "ulimit -a") and it's not
>>> permitted (to avoid DOS maybe), look for some grsec resource that
>>> impose limits to your stack and others (as open files, cpu time...),
>>> if it's related to grsec (as it seems to be) you will need to make
>>> this limit bigger.
>>
>> Sorry, but this isn't an answer I looking for. I know several ways how to
>> silence it - for example, I can just filter these records from logs.
>> My questions isn't "how to fix it", but "what is it" instead. Before
>> fixing something it's always good idea to understand what and why you're
>> fixing first.
>>
>> I don't understand these errors, and that's my problem.
>> If it's just "ulimit" thing, then it mean kernel should KILL these
>> processes. But this isn't happens - or there should be other noticeable
>> issues like undelivered mail or so, which I don't notice for now.
>>
>> --
>>                        WBR, Alex.
>>
>>
>