ディレクトリを見ていますが、/procユーザーが所有者とマークされていても、ユーザーとしてディレクトリを一覧表示できません。
なぜそしてどのようにこれが起こるのですか？
たとえば、とされていls -l /proc/2323/map_filesますls: reading directory '.': Permission denied。しかし、所有者は明らかにユーザーです。ユーザーはディレクトリにCDを挿入できますが、lsrootではできません。
後ろの話を追加：
現在、プロセスは大文字を削除して名前空間を分離するためにfirejail（setuidバイナリ）を使用しています。 Firejailがなければ、すべてが期待どおりに機能します。つまり、ユーザーはできますが、Firejailでは、ユーザーはls map_filesmap_filesディレクトリを使用できません。ディレクトリはユーザーが読み取ることができ、.soファイルへのシンボリックリンクであるファイルにもu + rが表示されるため、これは権限の問題ではありません。lscd
ベストアンサー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ユーザーがアクセスできなくなり、ルートのみアクセスできます。これは権限に反映されません。たとえば、setgidを実行するプロセスを考えてみましょう。このプロセスは予想されるユーザーが所有するすべてのファイルを所有し、/proc権限は権限のないプロセスと同じです。ただし、プロセスは追加のグループ権限を持つ間に機密情報にアクセスできるため、カーネルはユーザーがこの情報を除外できるようにすることはできません。たとえば、/proc/$pid/cwdプロセスが通常、ユーザーがアクセスできないディレクトリに変更された場合、ユーザーはプロセスが指しているものを見ることができません。ユーザーはプロセスのメモリをダンプできません/proc/$pid/mem。ユーザーは/proc/$pid/map*機密情報を反映している場合、プロセスのメモリマップを見ることはできません。ASLR効果的な）。など。