Почему пользователю root запрещен доступ к файлу?

Я хотел бы понять, в каких случаях root может быть отказано в доступе к файлу. Я работаю на машине, которую я не настраивал (на моем персональном ноутбуке у меня, очевидно, нет этой проблемы), и у меня возникла эта проблема, которую можно свести к следующему:

touch test.sh &&\
echo 'echo $PATH' >> test.sh &&\
sudo sh test.sh

выдаст ошибку: sh: 0: Can't open test.sh (bash: test.sh: Permission denied с bash).

  • Я попытался увидеть, был ли я под SELinux, запустивgetenforce, но команда не найдена.

  • Я старался sudo chown root test.sh, но это дает ошибку: chown: cannot access 'test.sh': Permission denied,

  • То же самое произошло при попытке изменить владельца каталога.

Я не обязательно прошу решение общей проблемы, но я хочу понять, как возможно, что root не имеет доступа.

РЕДАКТИРОВАТЬ

На той же машине, если я создаю локального пользователя (все вышеперечисленное было сделано как пользователь, вошедший в систему через общую сеть), все работает нормально.

Источник

1 ответ

д-р, если вы бежите

export PATH=.:$PATH # wrong

тогда ваш вышеупомянутый набор команд будет ~~ работать ~~, однако избегайте этого решения... Почему? ... когда вы запускаете исполняемый файл, давая ему полный путь

/my/cool/binary

или относительный путь

./../cool/binary # notice this begins with a ./  period slash

вы напрямую контролируете, откуда исходит исполняемый файл... однако, если по ошибке или по какой-то неестественной причине ваш env var PATH обновляется с добавлением dir(ов), который содержит (неправильные или вредоносные) исполняемые файлы с совпадающими именами

export PATH=/wrong/dir:/hackers/own/dir:$PATH

и вы просто используете

myexecutable_name  # using naked binary name

ты можешь бежать

/wrong/dir/myexecutable_name

когда ты намеревался бежать

/actual/good/dir/myexecutable_name

именно поэтому производственный код или что-либо, выполняемое от имени пользователя root, должно четко указать, откуда бинарный файл

Теперь вернемся к исходному вопросу... ваш код предполагает, что PATH включает в себя текущий каталог '.' который он не должен содержать для идентификаторов продуктов или root

export PATH=.:$PATH # wrong - bad for root or prod id yet handy for dev folks

вместо этого выполняйте с использованием полного пути... проблема в том, что вы хотите избежать возможности запуска неправильного двоичного файла, который находится в вашем текущем каталоге, когда вы намеревались запустить двоичный файл из стандартного каталога, как определено в вашем PATH

Не убежден? Потратьте некоторое время на качественный инфраструктурный код, особенно на пересечении между обязанностями... где двоичный файл команды B выполняет двоичный файл из команды A, и вы всегда увидите, что используется полный путь... Еще одним источником вдохновения является усиление конфликтов пространства имен

Источник
Другие вопросы по тегам