Чтобы продолжить ответ jasonwryan, я использую cut для обрезки начала известного целевого пути:
_c ()
{
local cur
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
case "$cur" in
*)
COMPREPLY=( $(compgen -f /src/$cur | cut -c 6-) )
;;
esac
return 0
} &&
complete -o filenames -F _c c
Это позволяет мне работать непосредственно с любым каталогом, подкаталогом или именем файла в / src /
Поведение, которое вы показываете, похоже, зависит от fs.protected_regular
параметра ядра Linux, введенного вместе с fs.protected_fifos
этой фиксацией (, объединенной в версии 4.19, я полагаю ), с целью исправить уязвимости безопасности.
Выдержка из сообщения фиксации (выделение мое):
namei: allow restricted O_CREAT of FIFOs and regular files
Disallows open of FIFOs or regular files not owned by the user in world writable sticky directories, unless the owner is the same as that of the directory or the file is opened without the O_CREAT flag. The purpose is to make data spoofing attacks harder....
В том же сообщении фиксации также содержится список связанных общих уязвимостей и рисков (CVE ).
Таким образом, при условии, что userX
является root
или иным образом предоставлен доступ на запись к /tmp/file
, и что /tmp
является доступным для записи каталогом с установленным липким битом, они могут открыть file
только для записи. если:
userX
является владельцем file
; или file
, и каталог /tmp
принадлежат одному и тому же пользователю. В вашем тесте root
имеет права на запись на /tmp/test.txt
,но не является владельцем файла, и /tmp/test.txt
и /tmp
не имеют одного и того же владельца (соответственно max
иroot
).
Проблема совершенно не связана со способом крепления /tmp
.
Соответствующая документация находится в Documentation/sysctl/fs.txt:
protected_fifos:
The intent of this protection is to avoid unintentional writes to an attacker-controlled FIFO, where a program expected to create a regular file.
...
protected_regular:
This protection is similar to protected_fifos, but it avoids writes to an attacker-controlled regular file, where a program expected to create one.
When set to "0", writing to regular files is unrestricted.
When set to "1" don't allow O_CREAT open on regular files that we don't own in world writable sticky directories, unless they are owned by the owner of the directory.
When set to "2" it also applies to group writable sticky directories.
То есть описанную выше защиту можно отключить командой:
sysctl fs.protected_regular=0
Небольшое тестирование в подтверждение нашей гипотезы:
$ su - root
# sysctl fs.protected_regular
fs.protected_regular = 1
# cd /
# mkdir test
# chmod 1777 test
# su - otheruser
$ echo hello >/test/somefile
$ exit
logout
# cat /test/somefile
hello
# ls -lah test/somefile
-rw-r--r-- 1 otheruser otheruser 6 Feb 26 17:21 test/somefile
# echo root >>test/somefile
-bash: test/somefile: Permission denied
# sysctl fs.protected_regular=0
fs.protected_regular = 0
# echo root >>test/somefile
# cat /test/somefile
hello
root
# sysctl fs.protected_regular=1
fs.protected_regular = 1
# echo root >>test/somefile
-bash: test/somefile: Permission denied
# chmod 0777 /test/
# echo root >>test/somefile
# cat test/somefile
hello
root
root
В отличие от fs.protected_hardlinks
и fs.protected_symlinks
, fs.protected_regular
и fs.protected_fifos
не включены по умолчанию в коде ядра.
Включение их является изменением, несовместимым с предыдущими версиями (, как показано в примере, который вы предоставили в , этот комментарий указывает ), и, насколько я могу судить, systemd
сделал это в версии 241 с . ] этот недавний коммит .
Кредиты :благодаря JdeBP за указание в правильном направлении с комментарием к вопросу.