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.=