Messages in this thread | | | Date | Mon, 10 May 2004 15:47:06 -0700 | From | Andrew Morton <> | Subject | Re: 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/
| |