Проверка времени изменения файла (с привилегиями). Как правильно?

[Victor Vislobokov]

В общем, если дело идёт о проверки времени изменения файла, если для него есть права у zabbix'а, то проблем нет.
Но вот что делать, если нужно контролировать время изменения тех файлов, до которых у zabbix'а нет доступа, например /root/.ssh/authorized_keys или /var/spool/cron/root?
Напрашивается вариант через sudo, но что дать sudo, чтобы zabbix мог контролировать только то что надо, не более того?
Пока могу лишь придумать вариант с кастомным скриптом, который будет строго выдавать только команды на получение времени изменения файла и ничего больше, но это громоздкий вариант, потому что к нему надо: первое - сам скрипт, второе - прописывание доп. файлов в /etc/zabbix/zabbix-agentd.d.
Может есть какие-то более простые и правильные варианты, о которых я не знаю?

[Kos]

Теоретически, можно воспользоваться дополнительными ACL-ами с помощью утилиты setfacl (если это позволяет ваша файловая система и используемые опции её монтирования).

Например, следующая пара команд даст право членам группы zabbix читать сейчас конкретный файл /var/log/messages, а также все вновь создаваемые в этой директории файлы (на случай ротации):

setfacl -dm g:zabbix:r /var/log
setfacl -m g:zabbix:r /var/log/messages

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

Не уверен, правда, что это будет работать с папками ~/.ssh (там, вроде, отдельные проверки на права доступа - надо пробовать).

[Victor Vislobokov]

Да, это ещё один вариант, но меня убивает количество дополнительных движений. Это мне надо каждый раз, когда мне нужен будет такой файл, идти на сервер и делать для него ACL (и для пути к нему, если он зарыт в глубине каталогов). Тогда уж проще через sudo дать права на /bin/stat всего ОДИН раз да и юзать. Идеально было бы иметь какой-то механизм повышения привилегий для агента на определённые ключи, но это чую фантастика

Ещё один вариант приходит в голову: сделать по cron'у от root'а скрипт, который будет обходить по указанному списку файлы и формировать сводку по ним, которая уже будет доступна на чтение zabbix'у. Тоже вариант так себе...

[Alex_UUU]

А включи в судо разрешение заббиксу выполнять команду ls.
И, вроде бы все проблемы будут сняты

[Victor Vislobokov]

А вы так пробовали? Почему вы думаете, что ZA использует команду ls для чтения отметок времени, а например не stat? Или вообще никакую команду не использует, а использует библиотечный вызов?

[Alex_UUU]

Вопрос ведь не в команде, а в доступах. Я предложил вариант получения доступов. А дальше зависит от того, как вы время изменения используете.
Например мне необходимо мониторить просто изменение. В данном случае я скармливаю ls в md5 и дифф в триггере.Если нужно в ЭД получить еще и время, тогда ls -> awk и время. но права все равно через судо.

[Victor Vislobokov]

Т.е. вы мне предлагаете сделать внешнюю команду, которой дать права через sudo? Такой вариант есть и я о нём писал в самом начале, вот только нельзя просто просто так взять и выполнить команду на ZA. Надо либо открывать доступ к вызову внешних команд, а это небезопасно даже с правами пользователя zabbix, либо писать кастомный файл в /etc/zabbix/zabbix_agentd.d где описывать ключ и запуск команды по нему, а это уже геморно, потому что куча дополнительных и лишних движений.

[Alex_UUU]

Либо что-то не понимаю, либо одно из двух:

Напрашивается вариант через sudo, но что дать sudo, чтобы zabbix мог контролировать только то что надо, не более того

?

Дать судо на ls вопросы все снимутся.
Никаких кастомных файлов, никаких доп скриптов. Весь скрипт умещается в систем ран.
Имхо, это самый безопасный, простой и рабочий вариант.

[Victor Vislobokov]

Что-то не пойму. Ну дам я sudo на ls для пользователя zabbix, а дальше что? Как запросить-то с сервера этот самый ls?

[Alex_UUU]

Например так:
system.run[''sudo ls -aln /var/spool/cron 2>/dev/null |md5sum 2>/dev/null'']

[Victor Vislobokov]

Тремя постами выше я написал:

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

а выполнение system.run по-умолчанию невозможно - эту штуку надо включать на ZA. И правильно, что нельзя. Есть куча локальных уязвимостей в Linux'ах, при наличие которых возможность запуска локальной команды - это возможно получить root'а на сервере.
Так что:

Имхо, это самый безопасный, простой и рабочий вариант.

Не самый простой (два доп. дейсвтвия):
1. Разрешить runtime команды
2. Установить кастомные права на sudo
Да. рабочий, но СОВСЕМ не безопасный