bin/174831: geli segfaults with the new locked memory limit default
Andrey Zonov
zont at FreeBSD.org
Fri Jan 18 09:51:06 UTC 2013
On 1/17/13 6:00 PM, Fabian Keil wrote:
> 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
>
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 = mlock( p, n );
169 if( err && errno )
170 err = 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.
--
Andrey Zonov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 535 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130118/9b92b1bf/attachment.sig>
More information about the svn-src-all
mailing list