Вопросы Теги

Существует ли инструмент/метод для самоанализа разрешений?

Я написал это в комментарии, потому что не понимал, что это уже решение. ОП написал, что это работает, так что на этот раз в качестве ответа:

sed "s/\(name=\"port\" *value=\"\)[0-9]*/\1$NEWPORT/g" config.xml

Регулярное выражение, предложенное OP, использовало несколько нестандартных расширений -, поэтому оно не работало с sed, но они вам не нужны:

Я использую sed -i для замены значения порта в XML-файле,

Но я не знаю, как избежать регулярного выражения, мое регулярное выражение ниже.

  • вместо «обратного просмотра» (?<=somestring)вы можете использовать строку как есть, но в \(somestring\)пометить ее как подвыражение и повторно использовать в замене как \1, поэтому вместо того, чтобы говорить «это нужно быть там, но не быть замененным», просто заменить его собой
  • +— это сокращение для\{1,\}(одного или нескольких вхождений ), но вы также можете заменить a+на aa*. В этом случае, вероятно, лучше использовать простую *, потому что нулевые вхождения невозможны
  • \dчитается не лучше, чем [0-9],по-моему
  • \sможно заменить на [[:space:]]или [ <literal tab>]. Здесь работает простой пробел

Заключение :Почти всех расширений reg -ex можно легко избежать, что может привести к немного длинному шаблону или трудностям для чтения, но часто без каких-либо недостатков. Исключением является не -жадное соответствие. :В некоторых случаях вам нужна другая концепция без них.

1
30.07.2020, 20:02
2 ответа

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

  1. Что делала команда, когда сталкивалась с ошибкой отказа в доступе?
  2. Почему это привело к ошибке отказа в доступе?

Что делало командование?

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

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

По умолчанию все записывается в stderr, но его можно настроить для записи в файл с помощью переключателя -o.

Приведу простой пример. Мы можем настроить тривиальный случай, чтобы заставить rmпотерпеть неудачу с этим:

$ sudo mkdir foo
$ sudo touch foo/bar
$ rm -rf foo
rm: cannot remove 'foo/bar': Permission denied

Чтобы показать, как может помочь strace, запустим ту же команду rm:

$ strace -o trace_file rm -rf foo
$ grep EACCES trace_file
unlinkat(4, "bar", 0)                   = -1 EACCES (Permission denied)

Таким образом, это показывает, что вызов unlinkat не смог удалить файл barиз уже открытого каталога.

Хотя мы уже знали, что так будет, мы настроили его на провал. Это может быть полезно для диагностики более сложных команд с более плохим выводом.

Я не знаю инструмента, который бы определял, почему что-то привело к ошибке отказа в доступе, однако причин относительно немного.

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

Два других источника, которые могут регулярно выявлять людей::

2
18.03.2021, 23:16

Нет особого смысла проверять это на основе команды, потому что вы должны знать, что команда собирается сделать:

  • Создать новый файл или каталог
  • Чтение существующего файла
  • Записать существующий файл
  • Выполнить существующий файл
  • Удалить или переименовать существующий файл или каталог
  • Переход в каталог

Разрешения не имеют значения, какая программа пытается выполнить эти операции. Одна и та же команда может делать разные вещи в зависимости от ее аргументов или среды.

1
18.03.2021, 23:16

Теги

Похожие вопросы