Date: Fri, 2 Apr 2004 00:29:57 +0200
From: Andrea Arcangeli <andrea@suse.de>
To: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org,
       kenneth.w.chen@intel.com
Subject: Re: disable-cap-mlock
Message-ID: <20040401222957.GZ18585@dualathlon.random>
References: <20040401135920.GF18585@dualathlon.random> <Pine.LNX.4.44.0404011443250.5589-100000@chimarrao.boston.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0404011443250.5589-100000@chimarrao.boston.redhat.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1298
Lines: 31

On Thu, Apr 01, 2004 at 02:44:50PM -0500, Rik van Riel wrote:
> On Thu, 1 Apr 2004, Andrea Arcangeli wrote:
> 
> > This is a lot simpler than the mlock rlimit and this is people really
> > need (not the rlimit). The rlimit thing can still be applied on top of
> > this. This should be more efficient too (besides its simplicity).
> 
> What use is this patch ?
> 
> One of the main reasons for the mlock rlimit is so that
> security conscious people can let normal users' gpg
> mlock a few pages.
> 
> This patch isn't usable for that at all, since switching
> the sysctl on would just open up the system to an easy
> deadlock by any user.  Definately not something any
> security conscious admin would want to enable ...

there's no way the rlimit patch can cover shmget(SHM_HUGETLB) and
shmctl(SHM_LOCK). That's the use of this patch.

Plus it obsoletes the need of setting rlimit for apps like databases.

the rlimit patch remains useful for the multiuser system you're talking
about (assuming you also limit the number of tasks per-user
accordingly).
-
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/