On 03/03/2015 05:32 AM, John Rose wrote: > Most Java codes use FileOutputStream to write a file. We could change its > behavior to delete its output file instead of truncating. This could be > fine-tuned > by various knobs (properties, callbacks, etc.). Then if the offending code > uses > Java to write a file, it would no longer tickle this class of bugs.
On some systems, this may introduce a security vulnerability if the file is in a shared directory for temporary files. Regarding the original mapping problem, Linux prevents this failure scenario for executable files (the ETXTBUSY error code). The triggering conditions for that are a bit bizarre. It seems this only applies to the main executable file, and not objects which are mapped subsequently. This is not too surprising because other options would allow unprivileged users to prevent modification of any file. -- Florian Weimer / Red Hat Product Security