[Bug libc/12155] MALLOC_MMAP_THRESHOLD_ and MALLOC_MMAP_MAX_ have different effect for setgid than for setuid programs

["eerott at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12155

Eero Tamminen <eerott at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eerott at gmail dot com
            Summary|MALLOC_MMAP_THRESHOLD_ and  |MALLOC_MMAP_THRESHOLD_ and
                   |MALLOC_MMAP_MAX_ (wrongly)  |MALLOC_MMAP_MAX_ have
                   |have effect in setgid       |different effect for setgid
                   |programs                    |than for setuid programs

--- Comment #5 from Eero Tamminen <eerott at gmail dot com> 2011-07-30 16:28:43 UTC ---
After quick glimpse at the (v2.11) malloc.c, the effect of these variables is:

* MALLOC_MMAP_MAX_ : how many simultenous mmap() requests glibc allocator can
do before falling back to heap (or asserting?)

* MALLOC_MMAP_THRESHOLD_ : which sized allocs will use mmap() instead of heap

I.e. these affect only to what size program's heap may grow and how many
mmap()s the program causes with its allocations.

The threshold value can be only between 4KB and:
--------
#ifndef DEFAULT_MMAP_THRESHOLD_MAX
  /* For 32-bit platforms we cannot increase the maximum mmap
     threshold much because it is also the minimum value for the
     maximum heap size and its alignment.  Going above 512k (i.e., 1M
     for new heaps) wastes too much address space.  */
# if __WORDSIZE == 32
#  define DEFAULT_MMAP_THRESHOLD_MAX (512 * 1024)
# else
#  define DEFAULT_MMAP_THRESHOLD_MAX (4 * 1024 * 1024 * sizeof(long))
# endif
#endif
--------

Only issue that I could think with these is that program can use a lot more
memory and/or be slower.  If it does enough allocs and mmap threshold is set to
4kB, app might crash due to running out of address space, but I think that's
all.  But if user is able to run the program to set its environment variables,
he's able to kill it directly too.  And slowdown can be gotten by running other
programs.

With this one may be able to trigger allocation failure earlier.  If program
doesn't handle allocation failures properly (AFAIK e.g. Glib & Qt by default
abort on them), its memory may get corrupted.  However, you can get this
simpler just by lowering resource limits lower before running the program.

As a conclusion, I don't see this as a security issue, but consistency one.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.