unix – 文件创建模式掩码

问题是：

>守护程序创建文件(或目录)时会发生什么？
>守护程序启动时umask的值是多少？

第一个问题的答案是守护进程可能使用八进制模式(如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会发生什么 – 结果不太可能是想要的.