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