Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Apr 2008 15:55:05 -0400
From:      David Schultz <das@FreeBSD.ORG>
To:        Joe Marcus Clarke <marcus@FreeBSD.ORG>
Cc:        mezz7@cox.net, imp@FreeBSD.ORG, current@FreeBSD.ORG, Coleman Kane <cokane@FreeBSD.ORG>
Subject:   Re: mlock(2), unprivileged users, and RLIMIT_MEMLOCK
Message-ID:  <20080412195505.GA36208@zim.MIT.EDU>
In-Reply-To: <1208028217.82222.32.camel@shumai.marcuscom.com>
References:  <1208027381.1327.31.camel@localhost> <1208028217.82222.32.camel@shumai.marcuscom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080412195505.GA36208>