On 1/17/13 6:00 PM, Fabian Keil wrote: > Konstantin Belousov <kostik...@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 <z...@freebsd.org> wrote: >>>> >>>>> On 1/14/13 3:26 PM, Fabian Keil wrote: >>>>>> Andrey Zonov <z...@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@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
signature.asc
Description: OpenPGP digital signature
