A file mode of 0644 or 0600 do not restrict the file owners options as the owner can still read/update/delete the file.

Let me quote man perlopentut

       Permissions A la mode

       If you omit the MASK argument to "sysopen", Perl uses the
       octal value 0666.  The normal MASK to use for executables
       and directories should be 0777, and for anything else,
       0666.

       Why so permissive?  Well, it isn't really.  The MASK will
       be modified by your process's current "umask".  A umask is
       a number representing disabled permissions bits; that is,
       bits that will not be turned on in the created files' per­
       missions field.

       For example, if your "umask" were 027, then the 020 part
       would disable the group from writing, and the 007 part
       would disable others from reading, writing, or executing.
       Under these conditions, passing "sysopen" 0666 would cre­
       ate a file with mode 0640, since "0666 & ~027" is 0640.

       You should seldom use the MASK argument to "sysopen()".
       That takes away the user's freedom to choose what permis­
       sion new files will have.  Denying choice is almost always
       a bad thing.  One exception would be for cases where sen­
       sitive or private data is being stored, such as with mail
       folders, cookie files, and internal temporary files.
[download]

Abigail

what if your umask is not set sanely?

what if your umask changes?

If you don't supply a mask to sysopen it will just create the file and apply the umask at create time.

Personally, I think paranoia is good and chmoding the file immediately after the create to most restricted mode possible while still making the file available to those processes and/or users that need to access the file is the best policy.

Abigail

I'm not wanting to start a flame here but I disagree on a couple of points:
Well, that's the user's choice, isn't? Who are you to determine whether a user has set his/her umask "sanely"? What umasks are sane, and which one aren't?

IMO it is very much the sys admins role to review security (including umasks) and make appropriate changes. Data files (critically important or otherwise) should not be world writable, group writable maybe, extended ACLs even, but not world writable.

Don't trust programmers who think they know better than the user what's good for them.

Agreed, its not up to the program to decide these things. These details should be in the functional spec the programmer is working from.

In general, you have no idea which processes or users are going to need access to the files created - so you better leave the decision what appropriate file permissions are to the user.

My experience with users is that generally they do not know what file modes/ownership is required to do what they need. The site I'm at now had a policy of all data files having a mode of 666. They had no idea of why 666 was a) unnecessary and b) bad. Staying with the site I'm at now, most of the users (6570 out of 6595) do not have shell access and wouldn't know a umask if it bit them. Their umask is set, they have no way of changing it, and for a long time the umask was set to '0' (which I would not call sane).

Every site is different and each has users of varying skills/knowledge and requirements. The point I was initially trying to make was: 'don't set the file access mode higher than it needs to be'.

CC

So, you think that programs like 'cp', or even perl (for files opened with 'open') should be restrictive, and always generate files with permission '0400' (why stop at 0600?)?

If the answer is yes, there's little point in using a umask, is there?

Their umask is set, they have no way of changing it, and for a long time the umask was set to '0' (which I would not call sane).

Ah, I see. So, because your site used to have a dumb policy, all programs should create files with as restrictive permissions as possible? Now, that's what I call stupid. Fix your site-wide policies.

Abigail