From owner-freebsd-current@FreeBSD.ORG Sat Apr 12 19:52:14 2008 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6771065674; Sat, 12 Apr 2008 19:52:14 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id B43558FC13; Sat, 12 Apr 2008 19:52:13 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m3CJtAc6036329; Sat, 12 Apr 2008 15:55:10 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m3CJtA59036328; Sat, 12 Apr 2008 15:55:10 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 12 Apr 2008 15:55:05 -0400 From: David Schultz To: Joe Marcus Clarke Message-ID: <20080412195505.GA36208@zim.MIT.EDU> Mail-Followup-To: Joe Marcus Clarke , Coleman Kane , mezz7@cox.net, imp@FreeBSD.ORG, current@FreeBSD.ORG References: <1208027381.1327.31.camel@localhost> <1208028217.82222.32.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1208028217.82222.32.camel@shumai.marcuscom.com> Cc: mezz7@cox.net, imp@FreeBSD.ORG, current@FreeBSD.ORG, Coleman Kane Subject: Re: mlock(2), unprivileged users, and RLIMIT_MEMLOCK X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2008 19:52:14 -0000 On Sat, Apr 12, 2008, Joe Marcus Clarke wrote: > On Sat, 2008-04-12 at 15:09 -0400, Coleman Kane wrote: > > Hello, > > > > Recently we've been having a discussion on the GNOME list about fixing > > the seahorse breakage introduced with the latest GNOME 2.22, rooted in > > the fact that FreeBSD's mlock(2) implementation is only usable if you > > have superuser privileges. Due to bugs in seahorse, the lack of mlock(2) > > causes many seahorse applications to die. I've posted a suggested patch > > to [...] > > As a third idea, we could leave the per-process limit (to abide by > > historical documentation), but also add a sysctl that enforces a > > system-wide "max mlock pages" which can be tested by the mlock(2) > > syscall, refusing to mlock(2) more memory if the limit is hit. > > I think this already exists in -CURRENT: vm.max_wired ("System-wide > limit to wired page count"). This is tested by mlock(2) in addition to > RLIMIT_MEMLOCK. First of all, many other operating systems such as Solaris also restrict mlock(2) to the superuser, so this is a bug in seahorse. That said, it seems like allowing ordinary users to mlock(2) small amounts of memory (e.g., vm_page_max_wired / 4 across all non-superuser processes by default) would fix your problem and be easy to implement. Of course, per-user or per-process limits would be more flexible, but how many people really have lots of users who are trying to abuse the system?