Как установить файл, который принадлежит пользователю, но не может быть прочитан владельцем?
Из нескольких тестов xfce4-screenshooterс использованием его графического интерфейса я пришел к выводу, что в xfce4-screenshooterесть ошибка, связанная с выделением места для снимка экрана.
У меня дисплей 1920x1080. Если сделать скриншот полноэкранного режима или скриншот развернутого окна (, который исключает области с панелями рабочего стола ), то копирование в буфер обмена и вставка завершатся ошибкой. Однако, если развернутое окно уменьшено в размере на небольшую, но незначительную величину, то скриншот окна, копирование в буфер обмена и вставка работают.
Думаю, следующим шагом будет отправка отчета об ошибке, если он еще не отправлен.
Сделать файл, принадлежащий пользователю, но недоступным для чтения тому же пользователю, на самом деле очень просто:
chmod u-r file
Если вы сделаете это -, единственным способом прочитать файл будет повышение ваших привилегий или возврат флага чтения(u+r).
То же самое касается каталогов. Снимите с него пользовательский -флаг чтения, и владелец каталога не сможет lsего прочитать. Снимите флаг исполняемого файла с каталога (u-x), и владелец потеряет возможность доступа cdк этому каталогу.
В то же время -к этим файлам и каталогам могут получить доступ другие люди(o+rиo+x). И, конечно же, они всегда доступны root , который игнорирует флаги разрешений.
Каталоги и файлы в каталоге /procпредставляют процессы, потоки, объекты разделяемой памяти. Их разрешения устанавливаются приложением при создании потока/разделяемой памяти. Поэтому они не реагируют на инструмент chmod, а попытка изменить разрешение — верный способ сломать работающее приложение. Но lsи cdпо-прежнему подчиняются флагам разрешений для объектов в /proc. Так что, если вам действительно нужно что-то там прочитать -, вы должны подняться до root .
Вы можете удалить разрешение на чтение файла, которым владеете, и больше не сможете его читать.
$ 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 эффективным ). И так далее.