Having had a bit more time to think on this (also more caffine), I still think a mask of 0666 with sysopen is less than desirable for a couple of reasons:
- 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.

CC

Read my post carefully. The mode given to sysopen is not the file permission mode. The resulting file permission mode is the result of the mode given to sysopen, masked by the umask.

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

Read my post carefully. I said A mode of 0666 gives the user the option to say who can read/write the file, which is something entirely different from the permissions of the owner of a 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

Well, you modified your post, so you get a second reply. You're still wrong though.

what if your umask is not set sanely?

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?

what if your umask changes?

Well, what about?

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

Djee. If you don't supply a mask to sysopen, sysopen will use 0666 or 0777. That doesn't result in less permissions than supplying 0666.

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.

I agree paranoia is good. Don't trust programmers who think they know better than the user what's good for them. 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.

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