|
|
Subscribe / Log in / New account

Another old security problem

Another old security problem

Posted Sep 10, 2010 23:14 UTC (Fri) by daglwn (guest, #65432)
In reply to: Another old security problem by rilder
Parent article: Another old security problem

Absolutely. Many scientific codes regularly exceed this amount of stack.


to post comments

Another old security problem

Posted Sep 11, 2010 0:02 UTC (Sat) by jspaleta (subscriber, #50639) [Link] (1 responses)

I would not call scientific codes... normal.. nor the people who run them.

-jef

Another old security problem

Posted Sep 11, 2010 4:29 UTC (Sat) by Trelane (subscriber, #56877) [Link]

Hey! I represent that remark.

Another old security problem

Posted Sep 11, 2010 10:50 UTC (Sat) by rilder (guest, #59804) [Link] (2 responses)

What I implied through that comments is this - in regular desktop environments it won't happen(cat /proc/**/status | grep -i vmstk didn't reveal more than 100-200 KB) . However, higher stack usage may be visible in applications in enterprise or as you said scientific establishments. Though, in such conditions the applications/packages installed on the host remain stable over time and are carefully chosen with lot of testing, so any of these exploits may not find their place there.

Another old security problem

Posted Sep 11, 2010 14:01 UTC (Sat) by spender (guest, #23067) [Link] (1 responses)

I'm not sure you understand the meaning of 'exploit' or the difference between soft and hard limits.

-Brad

Another old security problem

Posted Sep 15, 2010 9:10 UTC (Wed) by nix (subscriber, #2304) [Link]

Rilder made a perfectly good point: applications do not generally need vast stacks (not even Emacs!). Thus it is reasonable to impose a hard limit.

That distros generally impose soft limits instead (for no particularly obvious reason in the case of stack size) is no barrier to imposing a hard limit yourself.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds