☰

为什么目录会设置粘性位而不设置可执行位？

tag-icon • tag-icon ubuntu permissions directory-structure sticky-bit
为什么目录会设置粘性位而不设置可执行位？

在 Ubuntu 14.04 中，列出目录的内容/var/spool/cron会为其ls -l内的目录提供以下权限（不相关的列被剪掉）：

drwxrwx--T daemon daemon atjobs
drwxrwx--T daemon daemon atspool
drwx-wx--T root crontab crontabs

在没有可执行位的目录上设置粘滞位有何目的？

答案1

从手册页sticky：

粘性目录

设置了“粘性位”的目录成为仅追加目录，或者更准确地说，成为限制删除文件的目录。仅当用户具有该目录的写权限并且该用户是该文件的所有者、该目录的所有者或超级用户时，该用户才可以删除或重命名粘性目录中的文件。此功能可有效应用于 /tmp 等必须可公开写入的目录，但应拒绝用户任意删除或重命名彼此文件的许可。

任何用户都可以创建粘性目录。有关修改文件模式的详细信息，请参阅 chmod(1)。

这样做的结果是，只有粘性目录中文件的所有者才能删除该文件。就表格而言cron，这意味着我不能进去并删除你的cron 表并将其替换为以下之一我的选择，即使我可能具有对该目录的写访问权限。也正是因为这个原因，/tmp才具有粘性。

答案2

在没有可执行位的目录上设置粘滞位有何目的？

drwx-wx--T 2 root crontab 4096 Apr 24 15:00 /var/spool/cron/crontabs/

您所看到的与 Debian 上的类似。目录做为所有者和组设置可执行位。仅对于所有者而言，粘性没有多大意义，因为根据定义，只有一个用户（并且所有者无论如何都可以覆盖粘性）。但对于该组来说，它与像 这样的全局可写目录一样重要/tmp，即普通用户无法删除属于其他用户的文件。

但为什么有人会成为该组织的成员呢crontab？

当然是能够修改他们的 crontab！ Debiancrontab使用 setgid 权限，因此允许任何常规用户使用自己的 UID 和 GID 访问该目录crontab。这比让他们crontab用 set运行稍微安全一些uid特权，因为使用户彼此分离。

-rwxr-srx 1 root crontab 36008 2015 年 6 月 11 日 /usr/bin/crontab

现在，正常情况下，目录中的文件由各自的所有者拥有和命名，如果crontab只允许删除用户自己的 crontab，应该不会有问题。像这样设置文件权限可以防止程序中出现错误，和使访问用户的实际 UID 相关，而不仅仅是他们的姓名。

相关内容