ディレクトリを調べています/procが、ユーザーが所有者であることが示されているにもかかわらず、ユーザーとしてディレクトリを一覧表示できません。
なぜ、そしてどのようにしてこのようなことが起こるのでしょうか?
たとえば、 では とls -l /proc/2323/map_files表示されますls: reading directory '.': Permission denied。しかし、所有者は明らかにユーザーです。ユーザーは ディレクトリに cd できますが、 はできませんls。ただし、これを root として実行することは問題ありません。
追加された背景ストーリー:
現在、プロセスは setuid バイナリである firejail を使用して、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もはやユーザーはアクセスできず、ルートのみにアクセス可能になります。これは権限には反映されません。たとえば、setgid で実行されているプロセスについて考えてみましょう。このプロセスは、 内のすべてのファイルを/proc想定されるユーザーが所有し、権限は非特権プロセスと同じになります。ただし、プロセスは追加のグループ権限を持っている間に機密情報にアクセスした可能性があるため、カーネルは、ユーザーがこの情報を抜き出す可能性のある操作を実行することを許可しなくなります。そのため、たとえば、/proc/$pid/cwdプロセスが通常ユーザーがアクセスできないディレクトリに変更された場合、ユーザーは が指しているものを確認できません/proc/$pid/mem。ユーザーは を介してプロセスのメモリをダンプできません。ユーザーは を介してプロセスのメモリマップを確認できません。/proc/$pid/map*機密情報が反映されている場合 (また、自動調整効果的です。など。
答え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フォルダ内に書き込むこともできます。