[MLton] Patch: @MLton dumpable-core

[Wesley W. Terpstra]

Without this patch MLton writes its entire heap to a temporary file  
when it is unable to allocate memory. This was necessary to handle  
address space fragmentation in programs using heap sizes 0.5-1.5GB.  
There are a number of problems with doing this by default:
1. The temporary directory (or hard drive in general!) might not exist
2. An attacker might be able to retrieve sensitive information from  
the heap (setuid programs do this too)
3. The core dump might unexpectedly fill up a user's quota, causing  
other programs to fail
4. Even worse, it might fill up the temporary directory's filesystem,  
causing other users' programs to fail
5. The windows port cannot delete open files, which means these  
temporary can files sometimes get left behind
6. Most importantly, no one expects their program to suddenly dump 1GB  
to disk

People who previously needed this option are now be better served by  
using the 64bit port. As there is far more address space, the  
fragmentation issue is avoided. However, it could be the case that  
some 32-bit users still find this useful, so the patch does not remove  
this feature outright.

The patch adds an option used as follows
./my-program @MLton dumpable-core -- <my-args>
which re-enables this behaviour. Programs will not by default create  
core dumps.

Setuid programs should be compiled with -runtime 'no-load-world stop'.  
This prevents an attacker from starting the program in an incorrect  
state and also prevents the use of 'dumpable-core' to trick an  
application into exposing sensitive information.

The patch also adds some hints in case the program runs out of memory.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dumpable.patch
Type: application/octet-stream
Size: 2706 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton/attachments/20071208/ce150dba/dumpable.obj
-------------- next part --------------