lkml.org 
[lkml]   [2017]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3
On Mon 10-07-17 11:24:55, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 8:59 AM, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > We will always need some gap inforcement.
>
> Considering the Java issue, that's rather questionable.
>
> We really can't be breaking libreoffice. That's like a big classic
> no-no - it affects normal users that simply cannot be expected to work
> around it. For them, it's a "my office application no longer works"
> situation, and they just think the system is flaky.

I completely agree that breaking LO is a no-go and we should strive to
find a way around it. One way to go is to increase the ulimit in the LO
start up script I suspect (this can be done in distributions and work
with the upstream LO to be done in future releases). Is it ideal? Not at
all! But let's face it, the Java usage of the mapping below the stack
is questionable at best (I would dare to call it broken) and I wory to
weaken otherwise useful mitigation based on a fishy application.

> Now, somebody who explicitly raised the stack limit past 24MB and gets
> bit because he also tries to use more than 6M of arguments - that's
> actually a different issue. Let's see if anybody ever even complains,
> and then we might make it a "only for suid binaries" thing.

Sure, I was not worried about suid only binaries. If we should restrict
the argument/env size then they should behave the same way. Otherwise we
just risk oddities. I am just questioning why do we need to cap the
thing at all. I simply do not see what additional protection does it
give.

--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2017-07-10 20:40    [W:0.050 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site