☰

Как неинвазивно проверить доступ к файлу на запись?

tag-icon • tag-icon shell-script files permissions scripting
Как неинвазивно проверить доступ к файлу на запись?

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

Я мог бы проанализировать вывод stat, но это кажется действительно сложным и, возможно, ненадежным, хотя я не уверен, насколько сильно выходные данные статистики различаются в зависимости от реализации и времени.

Я мог бы добавить данные в конец файла и посмотреть, получится ли, но это потенциально опасно по двум причинам, которые я могу себе представить:

  1. Теперь мне нужно удалить добавление, и в случае, если какой-то другой процесс запишет что-то в файл, это сразу же станет нетривиальной задачей, поскольку моя строка больше не будет последней.
  2. Любой процесс, читающий файл, может иметь произвольные требования к содержимому этого файла, и я мог просто сломать это приложение.

решение1

Просто используйте wфлаг -testполезность:

[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"

Обратите внимание, что если вы собираетесь записать в файл позже, все равно возможно, что вы не сможете записать в него. Файл мог быть перемещен, разрешения могли измениться и т. д. Также может случиться, что-wобнаруживает разрешения на запись, но вмешивается какой-то другой фактор, делающий файл недоступным для записи.

решение2

Другой подход:

if >> /path/to/file
then
    echo "writeable"
else
    echo "write permission denied"
fi

Будет предпринята попытка открыть файл для добавления, и, если это удастся, бегатьнет команды(т.е.,выполнить пустую команду) с выводом в файл. 

Помните, что это создаст пустой файл, если он не существовал.

Оператор -wкоманды testможет просто сделать a stat и затем попытаться выяснить, похоже ли, что у вас должен быть доступ. Мой вариант (выше) более надежен, чем testподход в некоторых особых условиях, потому что он заставляет проверку доступа выполнять ядро, а не оболочка. Например,

  • если файл находится в файловой системе, отличной от Unix, особенно если он удаленно смонтирован с файлового сервера, отличного от Unix, поскольку statможет вернуть значение режима, которое вводит в заблуждение.
  • если файл находится в файловой системе, смонтированной только для чтения.
  • если у файла есть ACL, и режим создает впечатление, что у вас должен быть доступ, но ACL его отклоняет, или наоборот.
  • если какая-либо система безопасности (AppArmor, SELinux, …) запрещает доступ к файлу.

решение3

G-man прав: [ -w ]не будетвсегдасказать правду. Здесь, чтобы справиться с несуществующим файлом иДоступ запрещенсообщение от shell:

( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null && 
  echo writable || 
  echo not writable

Обновлять: Выглядит пугающе, не так ли? Ну, это так. Хм... как бы это выразить... НЕ ИСПОЛЬЗУЙТЕ ЭТО, если вы не уверены, что находитесь в условиях, которые оно требует для работы, как ожидается. См. комментарий Стефана.

Какой же вывод тогда? Даже если [ -w ]не говорит правду, это единственная команда, котораянамеревалсядля выполнения работы. Если не получится, ну что ж, мы его обвиним, напишем отчеты об ошибках, и он будет работать в будущем. Лучше проверьте условия, при которых он работает, и используйте [ -w ]; напишите специальный код для особых случаев. Обходные пути имеют свои собственные условия.

[ -w /path/to/file ]

это лучшийаприори.

Связанный контент