我很难理解为什么Unix守护进程会将文件创建模式掩码设置为0.如果有人能揭开umask功能的神秘感，我将感激不尽。
答案 0 :(得分：8)
看起来好像你一直在看书，或者读一些代码，并发现他们建议将umask值设置为0.我从来没有完全相信它是最好的选择，但它很简单
问题是：
第一个问题的答案是守护进程可能使用八进制模式（例如444或644）创建文件。但是，当您使用0444或0644作为值调用open()时，该位在umask中设置也被删除 - 因此文件的实际权限可能比计划的守护进程更具限制性。
当然，这是否是一个主要问题取决于另一个问题的答案。我通常使用umask 022运行 - 对我创建的文件没有组或公共写入权限。如果我运行一个没有显式设置其umask的守护进程，那么它创建的文件将没有组或公共写入权限。没关系;我假设文件的权限通常不包括组或公共访问，所以没有问题。但是假设一个偏执的系统管理员使用037的umask运行（没有组写或执行，没有公共访问权限）;然后守护进程将创建实际权限为440或640的文件。
通过将umask设置为零，守护进程确保在创建文件时，它创建的文件的权限正是它在open()调用中指定的权限。这确实意味着守护进程需要注意不要向公众提供不适当的写入权限，特别是对组织进行分组。
很大程度上取决于守护进程的作用。许多守护程序以root权限运行，并且可以代表特定用户创建文件。 root运行的其他守护程序可能只为系统管理员创建文件。其他守护程序由特定用户（例如，DBMS的管理帐户）运行，并且可能具有不同的要求。这些守护程序可能由root启动，但转而成为DBMS管理用户，在此过程中失去root权限。对于这些不同类的守护进程，文件访问的要求可能完全不同。他们可能会以不同方式处理umask。但他们都建议确保umask是确定性的 - 通常。
但是，如果守护程序没有仔细编写，或者与系统管理员有不同的想法应该使用什么权限，但它确实将umask设置为0或其他已知值，系统管理员可能没有方法覆盖守护程序设置的默认权限。开源的一个优点是，如果需要，系统管理员可以修改代码以符合他的要求。
因此，建议守护进程将其umask设置为零，因为无论启动守护程序的用户的umask设置如何，都会确保统一行为。如果您正在编写守护程序，则其他确定性值可能在您的上下文中是合理的。你应该总是考虑如果一个白痴设置了umask 777会发生什么 - 结果不太可能是想要的。