我有一个项目文件夹，其中所有文件的权限都很混乱。我有一个坏习惯，就是把所有文件都设置为八进制权限 777，因为这解决了所有与安全无关的问题。然后 FTP 上传、文本编辑器创建的文件等都有自己的权限集，让一切都变得一团糟。我决定振作起来，开始按照应有的方式使用权限。
我认为 664 是我的所有文件和文件夹的良好默认值，我只需删除其他人对私人文件的权限，并为可执行文件添加 +x。
然而当我将项目文件夹改为 664 时：
$ sudo chmod -R 664。 $ ls ls：无法打开目录。：权限被拒绝
这对我来说毫无意义。我有读/写权限，并且我是项目文件夹的所有者。ls -l我的项目文件夹最左边的部分如下所示：
-rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r-- 5 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r-- 3 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r-- 4 codemonkey codemonkey ... drw-rw-r-- 5 codemonkey codemonkey ...
我认为这与目录的权限有关，但是什么？
答案1
执行位是遍历 *nix 目录所必需的。您无法cd进入没有执行权限的目录，如果许多实用程序需要目录上下文，这会以不明显的方式影响它们。请考虑：
$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo
# You can read the contents of the directory, but ls still complains.
$ ls foo
ls: cannot access foo/bar: Permission denied
bar
# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied
这一切的原因在于 stat() 的工作方式。摘自man 2 stat：
文件本身不需要任何权限，但是 - 对于 stat() 和 lstat() 而言 - 需要对指向该文件的路径中的所有目录具有执行（搜索）权限。
归根结底，递归chmod很少能达到您的预期，并且会破坏目录读取和执行权限，从而导致像您这样的意外结果。始终将目录权限与文件权限分开处理，以获得最佳结果。
答案2
您需要对目录的执行权限。
考虑
sudo find -type d -exec chmod +x {} +
更新：这是我对这种显然很奇怪的执行权限使用的合理化解释。
Unix（以及 Linux）几乎将所有内容视为文件。这扩展到磁盘和各种其他设备。它还包括目录。
传统的 Unix 文件系统有一组适用于文件的权限。因此，Unix 设计师必须为每个权限位找到一些有用的功能，以便在应用于非正常数据文件的“文件”时使用。
让我们考虑一下目录。最初，仅使用读取权限来决定某人是否可以访问目录似乎是合理的 - 例如生成目录中的文件列表及其大小和日期戳等。
但是，假设您希望普通用户能够运行 /usr/local/bin 中的程序，但您不希望他们能够在 /usr/local 中翻找以查看那里有什么。如果您只有读取权限，则无法阻止这种情况。
因此，执行权限（否则是多余的）用于控制是否允许您的 shell “遍历”目录，我们的意思是，不再查找需要查找和读取作为路径一部分的子目录详细信息的内容。这允许您仅在需要读取 /usr/local/bin 内容时才访问 /usr/local 目录。
因此 /usr/local 上的 +x 意味着您可以运行“/usr/local/bin/foo”，但 /usr/local 上的 +r 意味着您可以找出 /usr/local 中的所有内容，包括谁拥有它、每个文件有什么权限、它的大小等等。
以上内容是基于模糊的回忆和猜测。可能并不完全正确，但我相信它合理地解释了为什么“执行”意味着“能够遍历”。