我正在查看/proc目录，作为用户，我无法列出目录，即使它显示该用户是所有者。
为什么以及如何发生这种情况？
例如，其中ls -l /proc/2323/map_files说ls: reading directory '.': Permission denied。但所有者显然是用户。用户可以 cd 进入该目录，但不能ls.不过，以 root 身份执行此操作还是可以的。
添加背景故事：
目前，该进程正在使用 firejail（这是一个 setuid 二进制文件）来删除大写字母和命名空间隔离 firefox。如果没有 firejail，一切都会按预期工作，即用户能够ls map_files，但使用 firejail，map_files 目录不能ls由用户使用，尽管cd很好。这不是权限问题，因为该目录是用户可读的，并且作为 .so 文件的符号链接的文件也显示 u+r。
答案1
您可以从您拥有的文件中删除读取权限，然后您将无法再读取该文件。
$ echo hello >foo
$ chmod u=w,go+r foo
$ ls -l foo
--w-rw-r-- 1 gilles gilles 6 Oct 20 15:13 foo
$ cat foo
cat: foo: Permission denied
这对于安全性来说没有什么用处，因为所有者可以随时更改文件的权限。这只是权限工作方式的结果。
但是，这并不能解释您在 中看到的内容/proc。/proc是一个有点特殊的文件系统。对于“普通”文件系统，当进程打开文件（或列出目录，或读取符号链接的目标）时，内核会检查进程的凭据（即它以什么用户身份运行等），读取文件的权限，并检查凭据是否允许访问该文件。但/proc不是这样工作的。内核应用特定的检查，对于/proc.另外，当进程列出目录时，内核会生成权限，这些权限近似于打开文件时执行的检查。
特别是，如果进程正在或已经使用提升的凭据运行（通常setuid 或 setgid，其中的某些信息/proc用户无法再访问，只能root访问。这没有反映在权限中。例如，考虑一个正在运行 setgid 的进程。此进程将拥有预期用户拥有的所有文件/proc，并且权限将与非特权进程相同。但是，由于该进程在具有额外组权限的同时可能有权访问机密信息，因此内核不再允许用户执行可能排除此信息的操作。因此，例如，/proc/$pid/cwd如果进程已更改为用户通常无法访问的目录，则用户无法看到指向的内容。用户无法通过 转储进程的内存/proc/$pid/mem。用户无法查看进程的内存映射，/proc/$pid/map*以防它们反映机密信息（并且还可以保留ASLR有效的）。等等。
答案2
要设置一个用户拥有但不能被同一用户读取的文件实际上非常简单：
chmod u-r file
如果您这样做 - 读取文件的唯一方法是提升您的权限或返回读取标志 ( u+r)。
目录也是如此。从中删除用户读取标志，目录的所有者将无法访问ls它。从目录 ( u-x) 中删除可执行标志，所有者将失去cd进入该目录的能力。
同时 - 这些文件和目录可以被其他人访问（o+r和o+x）。当然，它们始终可以通过根谁忽略权限标志。
目录和/proc目录中的文件代表进程、线程、共享内存对象。它们的权限由应用程序在创建线程/共享内存时设置。因此，它们不会响应chmod工具，并且尝试更改权限是破坏正在运行的应用程序的必然方法。但ls仍然cd遵守 中对象的权限标志/proc。所以如果你真的需要在那里读一些东西 - 你必须提升自己根。
答案3
这是用户权利造成的。
例子：
[~] whoami
mm
[~] mkdir test
[~] echo "Hello World" > test/hello.txt
[~] ls -ld test
drwxr-xr-x 2 mm mm 4,0K 20. Okt 14:20 test
[~] chmod 111 test
[~] ls -ld test
d--x--x--x 2 mm mm 4,0K 20. Okt 14:20 test
[~] ls test
ls: cannot open directory 'test': Permission denied
[~, ERR:2] cat test/hello.txt
Hello World
[~] chmod 555 test
[~] ls -ld test
dr-xr-xr-x 2 mm mm 4,0K 20. Okt 14:20 test
[~] ls test
hello.txt
文件夹权限与文件权限不同。这x意味着您可以访问该文件夹，但无法查看它。要查看该文件夹，您还需要r。当然w意味着您可以写入该文件夹。