File creation mode mask

Question

I'm struggling to understand why would a Unix daemon set the file creation mode mask to 0. I'll be thankful if someone can demystify the umask function.

Answer 1

It looks as if you've been reading books, or maybe reading some code, and found that they recommend setting the umask value to 0. I've never been entirely convinced that it is the best choice, but it is simple.

The issues are:

• What happens when the daemon creates a file (or directory)?
• What was the value of umask when the daemon was started?

The answer to the first question is that the daemon is likely to create the file with an octal mode such as 444 or 644. However, when you invoke open() with 0444 or 0644 as the value, the bits that are set in the umask are also removed - so the actual permission on the file could be more restrictive than the daemon planned.

Of course, whether this is a major problem depends on the answer to the other question. I typically run with umask 022 - no group or public write access to files I create. If I run a daemon that does not explicitly set its umask, then the files it creates will be left without group or public write permission. That's fine; I hypothesized that the permissions on the files don't usually include group or public access, so there'd be no trouble. But suppose a paranoid system administrator ran with umask of 037 (no group write or execute, no access for public); then the daemon would create files with actual permissions of 440 or 640.

By setting the umask to zero, the daemon ensures that when it creates a file, the permissions on the files it creates are precisely those that it specifies in the open() call. It does mean that the daemon needs to be careful about not giving inappropriate write permission to public in particular, and maybe to group.

A lot depends on what the daemon does. Many daemons run with root privileges and may create files on behalf of specific users. Other daemons run by root may only create files for the system administrators. Other daemons are run by a specific user (for example, the administrative account for a DBMS), and may have different requirements. Such daemons might be started by root but switch to become the DBMS administrative user, losing the root privilege in the process. The requirements on file access may be quite different for these different classes of daemon. They may well handle umask differently. But they are all well advised to make sure that the umask is deterministic - usually.

However, if a daemon is not written carefully enough, or has different ideas from the system administrator about what permissions should be used, but it does set umask to 0 or another known value, the system administrator maybe left without a method to override the default permissions set by the daemon. One advantage of Open Source is that the system administrator could, if need so be, modify the code to obey his requirements.

So, it is recommended that daemons set their umask to zero because it ensures uniform behaviour regardless of the umask setting of the user who starts the daemon. If you are writing a daemon, other deterministic values could be reasonable in your context. You should always consider what would happen if an idiot had umask 777 set - the result is unlikely to be what was wanted.