From owner-svn-src-all@FreeBSD.ORG Fri Jan 18 09:51:06 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3444BDD0 for ; Fri, 18 Jan 2013 09:51:06 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFA02A94 for ; Fri, 18 Jan 2013 09:51:05 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg6so1953064lbb.13 for ; Fri, 18 Jan 2013 01:50:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=NvI6T9LMfLLUgcPpQJGvyFAJfstgPGzDkmRlSD8r6dA=; b=Y1HnegU2t105SwnxUax3cSWOFqwyKWoWXuUUiOH3PkAANXbq8oG5PM2/Gf/nHbI5Ts vYaAA651eLdYAjp9VavG4HGPFjd3C+sXAIzOiZaCPwqUBXnKkkvYHtCwniln0FXh2Vy1 lJGTDAr7fkXmDZzsN8u0v3ebelZ00JxUKX9qM0PFkhCIVBxfVWzEAXcWXQNsj7BYtkAv HXXFxNgDtN3WAWdMFhDMAKGJ+I5LgjQPstYNO3djAQ40rTDet1OFm75acqNQBkmfPlr5 ywk6o4U+imx0EfBshaQV2Ti6IUPfYFB2dFTJi2PDq7tHRrMQX+KWdFjDPpQOEggqhyYf +qxA== X-Received: by 10.152.109.146 with SMTP id hs18mr7891970lab.8.1358502659330; Fri, 18 Jan 2013 01:50:59 -0800 (PST) Received: from dhcp170-82-red.yandex.net (dhcp170-82-red.yandex.net. [95.108.170.82]) by mx.google.com with ESMTPS id ee5sm1820623lbb.14.2013.01.18.01.50.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 01:50:58 -0800 (PST) Sender: Andrey Zonov Message-ID: <50F91AFC.2050904@FreeBSD.org> Date: Fri, 18 Jan 2013 13:50:52 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fabian Keil Subject: Re: bin/174831: geli segfaults with the new locked memory limit default References: <201301141058.r0EAwK4q044423@svn.freebsd.org> <20130114122640.152cb041@fabiankeil.de> <50F4464A.7000903@FreeBSD.org> <20130114200914.7f3272d2@fabiankeil.de> <50F5AB7B.6090903@FreeBSD.org> <20130115212014.GD2522@kib.kiev.ua> <20130117150022.24373166@fabiankeil.de> In-Reply-To: <20130117150022.24373166@fabiankeil.de> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QUNHUMIKBGPOKNRGLQNX" X-Gm-Message-State: ALoCoQlih8temwVQHLcCEViqvGEHpn8/9Knv3fGvtJiOLqlU5VXG0guq5naOdXUNbxE/1o+/wOuI Cc: Konstantin Belousov , svn-src-all@freebsd.org, Andriy Gapon X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 09:51:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QUNHUMIKBGPOKNRGLQNX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/17/13 6:00 PM, Fabian Keil wrote: > Konstantin Belousov wrote: >=20 >> On Tue, Jan 15, 2013 at 11:18:19PM +0400, Andrey Zonov wrote: >>> On 1/14/13 11:09 PM, Fabian Keil wrote: >>>> Andrey Zonov wrote: >>>> >>>>> On 1/14/13 3:26 PM, Fabian Keil wrote: >>>>>> Andrey Zonov wrote: >>>>>> >>>>>>> Author: zont >>>>>>> Date: Mon Jan 14 10:58:20 2013 >>>>>>> New Revision: 245415 >>>>>>> URL: http://svnweb.freebsd.org/changeset/base/245415 >>>>>>> >>>>>>> Log: >>>>>>> MFC r244383: >>>>>>> - Set memorylocked limit to 64Kb for default login class. >>>>>>> This prevents unprivileged users to lock too much memory. >>>>>> >>>>>> Note that this causes geli segfaults when using sudo: >>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174831 >>>>>> >>>>> >>>>> The change should not affect stable, because new behavior was turne= d off >>>>> in stable. >>>> >>>> It's not exactly obvious, but by "this" I was referring to the chang= e >>>> in CURRENT. >>>> >>> >>> The solution which you proposed was refused by kib@ (add to CC) when = I >>> proposed it earlier. >> The limits purpose is to limit some resource usage. Having application= s >> that override the limits contradicts the user intent of keeping the >> limits working. >=20 > My "user intent" when running applications with sudo is that > they do whatever is necessary to get the job done. >=20 > geli usually only runs for a couple of seconds, there usually > aren't lots of parallel geli executions and the limit will > only be increased if geli is running with root privileges. >=20 > I agree that applications shouldn't blindly increase limits > without reason, but in this case I think a good reason exists. >=20 >> As a workaround, you could set the limit for your user account. >=20 > Or I could continue to use the patch ... >=20 > The main problem I see here is that the user has to figure out > the cause of the problem before a workaround can be applied. >=20 > "pid 3521 (geli), uid 0: exited on signal 11" looks like > a common application bug and gdb isn't particular useful > to diagnose the problem either. >=20 >> As a solution, change the offending application to only mlock() >> the sensitive pages. E.g. gnupg already does this, probably because >> it is portable. >=20 > I agree that only mlock()ing the sensitive pages is a nice idea > in theory. >=20 > gnupg is an interesting example because it isn't able to lock > the memory either: >=20 > fk@r500 ~ $echo blafasel | gpg --encrypt -o /dev/null > gpg: WARNING: using insecure memory! > gpg: please see http://www.gnupg.org/documentation/faqs.html for more i= nformation >=20 > The excerpt from gnupg-1.4.13/util/secmem.c's lock_pool(): >=20 > if( uid ) { > errno =3D EPERM; > err =3D errno; > } > else { > err =3D mlock( p, n ); > if( err && errno ) > err =3D errno; > } >=20 > n is 32768 here, but if I disable the now-bogus uid check or > run gpg with sudo, mlock() returns -1 anyway and errno is ENOENT > (like before the mlock() call). >=20 > Apparently the mlock()ing even fails when gpg's s-bit is set now, > although I'm reasonably sure that this used to work in the past > (at least it suppressed the warning). >=20 > Fabian >=20 The code that you copy/pasted is under HAVE_BROKEN_MLOCK. The code that is executed on my machine is: gnupg-1.4.13/util/secmem.c: 167 #else 168 err =3D mlock( p, n ); 169 if( err && errno ) 170 err =3D errno; 171 #endif and it works without errors. I do not have HAVE_BROKEN_MLOCK in my config.h: /usr/ports/security/gnupg1/work/gnupg-1.4.13/config.h:/* #undef HAVE_BROKEN_MLOCK */ Try to recompile gnupg and check whether HAVE_BROKEN_MLOCK is defined. --=20 Andrey Zonov ------enig2QUNHUMIKBGPOKNRGLQNX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQ+Rr/AAoJEBWLemxX/CvThQEIAJ55i5ZqFX3fu/2sqMTfiz4j MzsZzCVdu9bp4L+c0py2jxyCEhQytmf5hGyf9nWLmCUO3+kVATeWoLEDSA93aO+D /8E8rwsoGtwF18EXtTWU/oJXdospGnmVlcMercDCAcJcPjk5272pslXXtMQSzWI3 FvSUtlLnpBBdoAN0CL/7fSJZuX4WhL4XfIvmcX2dEag5PPJbOFY892vjfoYwXett fPRrtpaaARctAuaAcJwT9HWiXPNPDXVf0OgSvG60REaYfd+22v3zMYiSeVLd6l72 WaCRoTvokQ/YFcARrEjoKbGoMG2QlAskf5Yalop4qKZQSdMm+qW7fl825MoN1E4= =SFdD -----END PGP SIGNATURE----- ------enig2QUNHUMIKBGPOKNRGLQNX--