On 20/11/2011, at 5:09 PM, KOSAKI Motohiro wrote:
>>> I noticed when a file name argument is passed to the IO.copy_stream, the
>>> newly-created destination file has 0600 perms and is not respecting my
>>> normal umask (0022).
>> 
>> Sometimes the convention, 0666 by default, causes security problem:
>> It causes world writable files if users forget to set correct umask.
>> 
>> There are various umask related security problem:
>> CVE-1999-1572, CVE-2001-1322, CVE-2005-1841, CVE-2006-1587,
>> CVE-2006-3589, CVE-2007-6249
>> 
>> So I didn't use 0666.
>> 
>> 0600 may be too restrictive but you can use File.chmod to relax it.
> 
> If you don't follow normal convention intentionally, is there any
> reason to don't write a documentation explicitly?

I think documentation is the wrong answer. The security defects are not caused
by programs using mode 0666 - which they should do by default - but by the
user having set their umask incorrectly. Ruby should not attempt to prevent this
user error. There are situations where it's legal to create a file, but because of
setuid mode on the directory, it's not possible for the program to chmod the new
file. This problem can only be avoided by using the correct mode at creation.

If you feel that Ruby *must* do something to address the umask problem, then
please consider whether Ruby should save the startup umask into a global constant
before changing for a more restrictive setting. This allows the programmer to set
umask back and avoid the "nanny state" setting.

Still, I don't favour this anyway. To attempt to prevent programmers from creating
insecure programs by restricting functionality is a hopeless quest.