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