It looks like you were reading books, or perhaps reading some code, and found that they recommend setting the umask value to 0. I was never completely sure that this is the best choice, but it is simple.
Problems:
- What happens when a daemon creates a file (or directory)?
- What was the value of umask when running the daemon?
The answer to the first question is that the daemon is likely to create a file with octal mode, such as 444 or 644. However, when you call open() with 0444 or 0644 as the value, the bits that are set in umask are also deleted - so the actual file permission may be more restrictive than the planned daemon.
Of course, the question of whether this is a serious problem depends on the answer to another question. Usually I launch using umask 022 - there is no group or public access to the files that I create. If I run a daemon that did not explicitly install its umask, then the files it creates will be left without group permission or public recording. It's great; I suggested that file permissions usually do not include group or public access, so no problems. But suppose that a paranoid system administrator started with umask from 037 (no group writes or executes, does not have public access); then the daemon would create files with actual resolutions of 440 or 640.
By setting umask to zero, the daemon ensures that when creating the file, the permissions on the files it creates are exactly those that it specifies in the open() call. This means that the demon must be careful not to give unacceptable permission to record to the public in particular and possibly group together.
Much depends on what the demon does. Many daemons operate with root privileges and can create files on behalf of specific users. Other root daemons can only create files for system administrators. Other daemons are launched by a specific user (for example, an administrative account for a DBMS) and may have different requirements. Such daemons can be launched using root, but switch to become an administrative user of the DBMS, having lost root privileges in this process. The file access requirements can be completely different for these different daemon classes. They can handle umask differently. But they are all encouraged to make sure that umask is deterministic - usually.
However, if the daemon is not written enough or has different ideas from the system administrator about what permissions should be used, but it sets the umask value to 0 or another known value, the system administrator can be left without a method to override the default permissions set by the daemons. One of the advantages of Open Source is that the system administrator could, if necessary, change the code to fit its requirements.
So, it is recommended that daemons set their umask to zero, because it provides uniform behavior regardless of the umask setting of the user who runs the daemon. If you write a daemon, other deterministic values may be reasonable in your context. You should always consider what happens if an idiot installs umask 777 - the result is unlikely to be what you need.