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

Reply via email to