Я просматриваю /procкаталог и, как пользователь, не могу отобразить каталог, хотя в нем указано, что пользователь является его владельцем.
Почему и как это происходит?
Например, в ls -l /proc/2323/map_filesнем говорится ls: reading directory '.': Permission denied. Но владелец явно user. Пользователь может 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*если они отражают конфиденциальную информацию (а также для сохраненияАСЛР(эффективный) И так далее.
решение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означает, что вы можете писать в эту папку.