From owner-freebsd-current@FreeBSD.ORG Tue Apr 15 01:47:27 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 839A51065671 for ; Tue, 15 Apr 2008 01:47:27 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5294B8FC18 for ; Tue, 15 Apr 2008 01:47:27 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id DbrD1Z0020EPchoA80Ab00; Tue, 15 Apr 2008 01:46:07 +0000 Received: from discordia ([24.60.135.75]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id DdnR1Z00A1dmTCQ8M00000; Tue, 15 Apr 2008 01:47:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=uaUJgS5ZL84A:10 a=FkP6uzeq5BwA:10 a=pPofJSkepftU0-rcoawA:9 a=81x8KFjfpkM0sI5OFywA:7 a=KIvCOl5erWIVKthaTJRNGC7tG1QA:4 a=LY0hPdMaydYA:10 a=oE8HoHwhu26u-RBab0cA:9 a=qa6rO3kymUhFtoJp7NfrMDekg6AA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id 2C7A41636F9; Mon, 14 Apr 2008 21:47:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 66BD91636F8; Mon, 14 Apr 2008 21:47:11 -0400 (EDT) From: Coleman Kane To: David Schultz In-Reply-To: <20080412213808.GA38426@zim.MIT.EDU> References: <1208027381.1327.31.camel@localhost> <1208028217.82222.32.camel@shumai.marcuscom.com> <20080412195505.GA36208@zim.MIT.EDU> <1208032865.1424.9.camel@localhost> <20080412213808.GA38426@zim.MIT.EDU> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7QcQ3DHNQwz0JTOrLEgy" Organization: FreeBSD Project Date: Mon, 14 Apr 2008 21:46:47 -0400 Message-Id: <1208224007.1326.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Cc: mezz7@cox.net, Joe Marcus Clarke , imp@FreeBSD.ORG, current@FreeBSD.ORG 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: Tue, 15 Apr 2008 01:47:27 -0000 --=-7QcQ3DHNQwz0JTOrLEgy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-04-12 at 17:38 -0400, David Schultz wrote: > On Sat, Apr 12, 2008, Coleman Kane wrote: > > On Sat, 2008-04-12 at 15:55 -0400, David Schultz wrote: > > > On Sat, Apr 12, 2008, Joe Marcus Clarke wrote: > > > > On Sat, 2008-04-12 at 15:09 -0400, Coleman Kane wrote: > > > > > Hello, > > > > >=20 > > > > > Recently we've been having a discussion on the GNOME list about f= ixing > > > > > the seahorse breakage introduced with the latest GNOME 2.22, root= ed 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 m= lock(2) > > > > > causes many seahorse applications to die. I've posted a suggested= patch > > > > > to=20 > > > [...] > > > > > As a third idea, we could leave the per-process limit (to abide b= y > > > > > 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. > > > >=20 > > > > I think this already exists in -CURRENT: vm.max_wired ("System-wide > > > > limit to wired page count"). This is tested by mlock(2) in additio= n to > > > > RLIMIT_MEMLOCK. > > >=20 > > > First of all, many other operating systems such as Solaris also > > > restrict mlock(2) to the superuser, so this is a bug in seahorse. > > >=20 > > > 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? > > >=20 > >=20 > > I did some math and came up with the following per-user limit on my > > system. Using the default install, my maxproc is set to 5547: > > max_secure_mem =3D max_proc * memorylocked =3D 5547 * 16384 =3D 9088= 2048 =3D > > about 87MB > >=20 > > So, under my operating conditions (2GB System RAM), a user's maximum Do= S > > attempt would be capped at 87MB... which doesn't seem as serious > > anymore. This is using the 16K memorylocked value that gnome-keyring & > > friends seem to work fine with. >=20 > Yes, but why bother? A system-wide limit would still be far easier > to implement than keeping track of a per-process limit, and it > allows processes to lock more memory on single-user systems, while > keeping the overall limit low (since most processes don't lock > anything). >=20 > There are additional difficulties with per-process limits such as > deciding who to charge when multiple processes lock a shared > memory segment. If you charge one or the other, e.g., processes A > and B share a locked segment and you charge A, then B could exceed > its limit by locking another segment, then having A munlock(). If > you charge both processes, then mmap() on a segment that another > process has locked might fail. >=20 Hey guys, Would arch@ be a more suitable place to discuss this / probe for more info? --=20 Coleman Kane --=-7QcQ3DHNQwz0JTOrLEgy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgECQMACgkQcMSxQcXat5dSmwCfYvl2cMUP4rr8q/fBjKuwIjCv AfkAn17pkyNMiYWP7Hs8Z9v8z9zBfleC =Cy6N -----END PGP SIGNATURE----- --=-7QcQ3DHNQwz0JTOrLEgy--