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). >>=20 >> Sometimes the convention, 0666 by default, causes security problem: >> It causes world writable files if users forget to set correct umask. >>=20 >> 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 >>=20 >> So I didn't use 0666. >>=20 >> 0600 may be too restrictive but you can use File.chmod to relax it. >=20 > 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. Clifford Heath.=