lkml.org 
[lkml]   [2004]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.6-mm1
Christoph Hellwig <hch@infradead.org> wrote:
>
> On Mon, May 10, 2004 at 03:15:54PM -0700, Andrew Morton wrote:
> > It beats the alternatives which are floating about, which includes a sysctl
> > which defeats CAP_SYS_MLOCK system-wide.
>
> That one might not be nice, but at least it doesn't randomly change
> the meaning of a group id.

If you don't set the sysctl there is no change in system behaviour.

> So yeah, although it's a hack too it's
> much much better than the junk that just went into Linus tree.

Untrue. With the system-wide thing unprivileged local users can
trivially DoS the database.

> Why btw do we have a staging tree if such sensitive patches go into
> mainline without proper review after just one day?

It was discussed on lkml, then later was dicussed extensively off-list
and I lost track of how long it had been in -mm. Sorry.

> > > What happened to the patch rick promised
> > > to make mlock an rlimit? This is the right approach and could be easily
> > > extended to hugetlb pages.
> >
> > rlimits don't work for this. shm segments persist after process exit and
> > aren't associated with a particular user.
>
> When did shm segments come into the play? I know we bolted hugetlb
> support onto the back of the already horrible sysv shm interface, but
> if people want additional interfaces ontop of that they should use
> the proper mmap api.

Rewriting Oracle isn't a practical alternative.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.069 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site