From owner-freebsd-current@FreeBSD.ORG Sat Apr 12 20:57:36 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 6DEC8106567B for ; Sat, 12 Apr 2008 20:57:36 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 292A18FC1B for ; Sat, 12 Apr 2008 20:57:36 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id CjJe1Z0020b6N64A604l00; Sat, 12 Apr 2008 20:40:21 +0000 Received: from discordia ([24.60.135.75]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id CkhX1Z0011dmTCQ8P00000; Sat, 12 Apr 2008 20:41:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=uaUJgS5ZL84A:10 a=FkP6uzeq5BwA:10 a=zm4l488qJHa5x5m6BiQA:9 a=DS_9OH4MTqmHiGd5wawA:7 a=MCr99EwBFniTfJ85zDKmNACMGW4A:4 a=LY0hPdMaydYA:10 a=Ut70Zk3CFNj1pghtA14A:9 a=IlZ7Y1h5afJkATzx5IWQnLoy8XYA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id 0C8821636F8; Sat, 12 Apr 2008 16:41:31 -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 8F09B1636F9; Sat, 12 Apr 2008 16:41:20 -0400 (EDT) From: Coleman Kane To: David Schultz In-Reply-To: <20080412195505.GA36208@zim.MIT.EDU> References: <1208027381.1327.31.camel@localhost> <1208028217.82222.32.camel@shumai.marcuscom.com> <20080412195505.GA36208@zim.MIT.EDU> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BAw17Tz5ry9Tg5u3O+Qa" Organization: FreeBSD Project Date: Sat, 12 Apr 2008 16:41:05 -0400 Message-Id: <1208032865.1424.9.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: Sat, 12 Apr 2008 20:57:36 -0000 --=-BAw17Tz5ry9Tg5u3O+Qa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 fixin= g > > > the seahorse breakage introduced with the latest GNOME 2.22, rooted i= n > > > 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 pat= ch > > > to=20 > [...] > > > 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. > >=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 addition 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 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 90882048= =3D about 87MB So, under my operating conditions (2GB System RAM), a user's maximum DoS 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. -- Coleman Kane --=-BAw17Tz5ry9Tg5u3O+Qa 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) iEYEABECAAYFAkgBHlwACgkQcMSxQcXat5e6+gCeMpgeag0LznFwbRtUxA8UPYvJ 06QAn28SrMypfYIhhraZEQewN3C/gGF1 =xNh1 -----END PGP SIGNATURE----- --=-BAw17Tz5ry9Tg5u3O+Qa--