GNOME Bugzilla – Bug 646534
SELinux mmap_zero access
Last modified: 2018-06-29 22:56:03 UTC
I was working in the register when an autosave was unable to finish and set off the SELinux warning system, it appeared to be stuck in an endless loop, and asked to terminate the unresponsive application. It also generated another bug report: https://bugzilla.redhat.com/show_bug.cgi?id=690984 I am using svn20404 This is the first time I have had a problem with SELinux and GnuCash, the only thing I can think of different, is I left GnuCash open and running for about 70 hours, forgetting to close it down when I went home for the night, not sure if that could change anything, but it may have autosaved quite a bit during that time. This problem happened within the first 10 minutes or so of using it this morning. SELinux is preventing /usr/local/bin/gnucash from mmap_zero access on the memprotect Unknown. ***** Plugin mmap_zero (53.1 confidence) suggests ************************** If you do not think /usr/local/bin/gnucash should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ******************* If you want to control the ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr. Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. Do setsebool -P mmap_low_allowed 1 ***** Plugin catchall (5.76 confidence) suggests *************************** If you believe that gnucash should be allowed mmap_zero access on the Unknown memprotect by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep gnucash /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects Unknown [ memprotect ] Source gnucash Source Path /usr/local/bin/gnucash Port <Unknown> Host frontdesk.raleightile.com Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.9.7-37.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name frontdesk.raleightile.com Platform Linux frontdesk.raleightile.com 2.6.35.11-83.fc14.i686 #1 SMP Mon Feb 7 07:04:18 UTC 2011 i686 i686 Alert Count 42 First Seen Sat 02 Apr 2011 10:15:23 AM EDT Last Seen Sat 02 Apr 2011 10:15:38 AM EDT Local ID 7dc242a4-c94c-4b47-8a44-efa188103574 Raw Audit Messages type=AVC msg=audit(1301753738.130:2503): avc: denied { mmap_zero } for pid=22452 comm="gnucash" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect type=SYSCALL msg=audit(1301753738.130:2503): arch=i386 syscall=mmap2 success=no exit=EACCES a0=0 a1=1000 a2=3 a3=22 items=0 ppid=6066 pid=22452 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=15 comm=gnucash exe=/usr/local/bin/gnucash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Hash: gnucash,unconfined_t,unconfined_t,memprotect,mmap_zero audit2allow #============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'mmap_low_allowed' allow unconfined_t self:memprotect mmap_zero; audit2allow -R #============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'mmap_low_allowed' allow unconfined_t self:memprotect mmap_zero;
I'm starting to see this on a regular basis, 1-3 times per day, but I can't identify what is causing it.
Created attachment 186093 [details] GnuCash open as usual Notice the extremely high memory usage, it was 200M less 30 minutes ago.
Created attachment 186094 [details] 1 minute later, notice increased memory usage Pressing the refresh button 4 times, notice the increase in memory usage, almost every push is 3M increase in memory consumption
Could this be related to [r20496] src/app-utils/gnc-ui-util.c: Bug #645518: Partly revert r20378, "Correct memory leaks found with valgrind"
I don't think r20496 causes your bug here, because the parts that were reverted in r20496 were applied not too long ago (r20378), but this doesn't match your observation that this error now appears but didn't appear, say, several months ago. That other bug report says something about gnomevfs. Is your gnucash file stored on and accessed through a network drive? Maybe there is a problem in the gnomevfs network access layer? Then again, in comment#3 you said "pressing the refresh button", which means you are simply running the report again (without any file access), right? Oh, except that your report loads the logo image, so at least the logo file is loaded from some disk. Do you see a memory consumption increase also in reports that do not contain any external images?
Further investigation reveals that not all reports being refreshed increase memory consumption, the worst offenders are the Payable Aging and Recievable Aging. Trying different options has led me to believe the report option "Show zero balance items" being selected results in the memory consumption, without this selected there doesn't seem to be enough change to matter for a very long time. Once the SELinux error is tripped (the abrt light goes off) GnuCash is unresponsive, and although I have waited various amounts of time for it to recover, it never does, leaving me to terminate it. It is always locking up while in the process of an autosave and the progress bar at the bottom is always all but finished, it is just the last little bit that it hangs on. I speculate that is why the filesystem is involved. Also this is on a Fedora 14 system, so it could be a change in Fedora more than a change in GnuCash. I'll try and find more information, if I could determine how to trip this every time, I could figure out whether it is a Fedora issue or a GnuCash issue..
The GnuCash file is opened from /home/GnuCash/ and the logo from /home/GnuCash/Settings/gnucash.png although my current user directory is /home/brushb. the /home/GnuCash/ directory is owned by brushb. I did notice the SELinux Context for this directory is home_root_t , probably because I created the directory as root and then changed the owner and permisions. I changed it to User Data for now.
(In reply to comment #7) > The GnuCash file is opened from /home/GnuCash/ and the logo from > /home/GnuCash/Settings/gnucash.png ... and both directories are normal local disks with ext4 filesystem or similar? Also, does anyone know some further documentation for developers to understand what SELinux' error message about mmap_zero access means and how developers can debug and fix those? It sounds rather weird that the "Show zero balance items" has any significant effect on memory usage, because this option seems so unimportant in terms of what is being calculated.
Program received signal SIGABRT, Aborted. 0x00e7e416 in __kernel_vsyscall () Following instructions at: https://bugzilla.gnome.org/show_bug.cgi?id=646534 (gdb) bt full
+ Trace 226923
(In reply to comment #9) > Program received signal SIGABRT, Aborted. > 0x00e7e416 in __kernel_vsyscall () > > Following instructions at: https://bugzilla.gnome.org/show_bug.cgi?id=646534 > > (gdb) bt full > I started GnuCash yesterday with gdb and was rather disappointed to run all day with no crash, I left the program open all night, and then started using it again this morning with no crash, then after about 30 minutes of use, while typing an email it crashed in the background while doing an autosave. So far steps to reproduce: Use latest Fedora 14. Notice SELinux settings are: Enforcing, Enforcing, Targeted Use latest svn version of gnucash. Leave running for a long time.
After crashing gnucash said: (process:584): GLib-ERROR (recursed) **: gmem.c:170: failed to allocate 128 bytes aborting... Running from the command line: gnucash --debug --log gnc.scm=debug This is a development version. It may or may not work. Report bugs and other problems to gnucash-devel@gnucash.org. You can also lookup and file bug reports at http://bugzilla.gnome.org The last stable version was GnuCash 2.4.4 The next stable version will be GnuCash 2.6 (process:584): GLib-ERROR (recursed) **: gmem.c:170: failed to allocate 128 bytes aborting...
> It sounds rather weird that the "Show zero balance items" has any significant > effect on memory usage, because this option seems so unimportant in terms of > what is being calculated. I think the report memory usage should be a separate bug if it isn't related, I just happened to notice while poking around on this one, what do you think?
After crashing gnucash said: Program received signal SIGABRT, Aborted. 0x00bd1416 in __kernel_vsyscall () Steps to reproduce: Use latest Fedora 14. Notice SELinux settings are: Enforcing, Enforcing, Targeted Use latest svn version of gnucash. Leave running for a while. (not as long this time) (gdb) bt full
+ Trace 226934
(In reply to comment #12) > > It sounds rather weird that the "Show zero balance items" has any significant > > effect on memory usage, because this option seems so unimportant in terms of > > what is being calculated. > > I think the report memory usage should be a separate bug if it isn't related, I > just happened to notice while poking around on this one, what do you think? I can't tell if the memory problem is related, but it might very well be. A quick search on the web suggests other programs that have hit a similar issue and some suggest that the selinux mmap_zero access error can point at an out of memory problem. Since you claim that memory usage rises each time you open some reports, you may have discovered a memory leak in GnuCash. When you run GnuCash for a long period of time, this can fill all available memory. I note also that your comment 11 shows a GLib out of memory error (failed to allocate new bytes), which points in the same direction. By the way, I'm running F14 as well with selinux Enforcing/Targetted, but never experienced this problem. I must admit, I usually don't have GnuCash running for extended periods of time and neither do I use the reporting features a lot.
Both stack traces also seem to relate from an out-of-memory error and might indicate towards a memory leak in the qof_format_time() function, which is triggered each and every time a g_log message is written. Hence, this error should show up if you provoke a lot of debugging output, as with "gnucash --debug --log gnc.scm=debug" and then running a lot of scheme code that contains debug output. A similar out-of-memory error should appear if you open the data file a lot, as (I think) each object creation during data file loading creates plenty of debug messages as well. But the code from qof_format_time() looks as if there couldn't be a problem. The code is a bit weird and it is probably a performance penalty to allocate plenty of buffers each time a debug message is written, but it still doesn't look like a memory leak.
After installing the following package and doing a new make and install I no longer have this error, it must have been related in some way. https://bugzilla.gnome.org/show_bug.cgi?id=648915 Christian Stimming: You need to install the package libtool-ltdl-devel . It's a bug in Fedora's libguile-devel package requirements. https://bugzilla.redhat.com/show_bug.cgi?id=700509 http://lists.gnucash.org/pipermail/gnucash-devel/2011-April/031849.html
Now *this* is really weird. Whatever - I'm glad the error is resolved for you.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=646534. Please update any external references or bookmarks.