root не может записать в файл, принадлежащий другому пользователю
обнаружил вот такое интересное поведение:
root@host~# touch /tmp/some.file
root@host~# chown nobody /tmp/some.file
root@host~# echo 123 >> /tmp/some.file
-bash: /tmp/some.file: Permission denied
если запустить /bin/sh (на самом деле это /bin/dash), сообщение выглядит чуть иначе:
sh: 1: cannot create /tmp/some.file: Permission denied
происходит такое чудо, если файл создан в каталоге, принадлежащем root-у и имеющем набор прав ugo=rwx,o+t (обычно такой набор прав у каталогов /tmp, /var/tmp и т.п., но можно создать каталог с такой принадлежностью и правами в любом другом месте — поведение будет идентичное).
наблюдается в ubuntu версии 20.04 (программа linux версии 5.4.0, библитотека glibc версии 2.31).
apparmor, selinux — отсутствуют.
кто виновник такого поведения и где оно задокументировано? версии предполагаемых кандидатов (ubuntu, linux, glibc) я привёл, но, возможно, виноват кто-то ещё.
Ответы (1 шт):
кто виновник такого поведения и где оно задокументировано?
виновник — комплект программ под общим названием systemd.
начиная с версии 241 при загрузке по умолчанию включается параметр программы linux /proc/sys/fs/protected_regular (доступен начиная с версии 4.19 этой программы).
благодаря чему программа linux блокирует запись в файлы при выполнении определённых условий:
- при вызове функции
open()передаётся флагO_CREAT - файл принадлежит другому пользователю (не тому, кто пытается осуществить запись)
- файл находится непосредственно в каталоге:
- который доступен для записи всем пользователям
- у которого установлен «sticky bit» («restricted deletion flag»)
- владелец которого не совпадает с владельцем файла
каталогами, отвечающими условиям 3.1 и 3.2, по умолчанию являются такие каталоги как /tmp и /var/tmp.
возможные пути «обхода» этого ограничения:
отключить параметр (плохое решение):
$ sudo sysctl fs.protected_regular=0создавать файл в каталоге, не отвечающем условиям 3.1 и 3.2. например, в подкаталоге, созданном в каталоге
/tmp.
ссылки: