Date: Fri, 18 Jan 2013 13:50:52 +0400 From: Andrey Zonov <zont@FreeBSD.org> To: Fabian Keil <freebsd-listen@fabiankeil.de> Cc: Konstantin Belousov <kostikbel@gmail.com>, svn-src-all@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: bin/174831: geli segfaults with the new locked memory limit default Message-ID: <50F91AFC.2050904@FreeBSD.org> In-Reply-To: <20130117150022.24373166@fabiankeil.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <kostikbel@gmail.com> 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 <zont@FreeBSD.org> wrote: >>>> >>>>> On 1/14/13 3:26 PM, Fabian Keil wrote: >>>>>> Andrey Zonov <zont@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F91AFC.2050904>