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