bin/174831: geli segfaults with the new locked memory limit default (was: svn commit: r245415 - stable/9/etc)
Fabian Keil
freebsd-listen at fabiankeil.de
Thu Jan 17 14:00:41 UTC 2013
Konstantin Belousov <kostikbel at gmail.com> wrote:
> 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 at FreeBSD.org> wrote:
> > >
> > >> On 1/14/13 3:26 PM, Fabian Keil wrote:
> > >>> Andrey Zonov <zont at 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=174831
> > >>>
> > >>
> > >> The change should not affect stable, because new behavior was turned off
> > >> in stable.
> > >
> > > It's not exactly obvious, but by "this" I was referring to the change
> > > 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 applications
> that override the limits contradicts the user intent of keeping the
> limits working.
My "user intent" when running applications with sudo is that
they do whatever is necessary to get the job done.
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.
I agree that applications shouldn't blindly increase limits
without reason, but in this case I think a good reason exists.
> As a workaround, you could set the limit for your user account.
Or I could continue to use the patch ...
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.
"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.
> As a solution, change the offending application to only mlock()
> the sensitive pages. E.g. gnupg already does this, probably because
> it is portable.
I agree that only mlock()ing the sensitive pages is a nice idea
in theory.
gnupg is an interesting example because it isn't able to lock
the memory either:
fk at 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 information
The excerpt from gnupg-1.4.13/util/secmem.c's lock_pool():
if( uid ) {
errno = EPERM;
err = errno;
}
else {
err = mlock( p, n );
if( err && errno )
err = errno;
}
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).
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).
Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130117/99380057/attachment.sig>
More information about the svn-src-all
mailing list