Мы используем #include в файле sudoers для организации наших правил sudo для каждого приложения.
Наши настройки sudoers выглядят примерно так:
/etc/sudoers
-> #include /usr/local/etc/sudo/sudoers.master
-> #include /usr/local/etc/sudo/app1.sudo
-> #include /usr/local/etc/sudo/app2.sudo
-> #include /usr/local/etc/sudo/<...etc...>.sudo
/usr/local/etc это каталог, который мы синхронизируем на всех наших серверах.
Иногда нам нужны правила sudo для конкретного хоста, поэтому мы помещаем их прямо в / etc / sudoers. Все глобальное попадает в эти централизованно синхронизируемые файлы.
Когда я бегу visudo для редактирования локальных sudoers он открывается /etc/sudoers в vi без проблем. Когда я сохраняю свои изменения, я получаю запрос:
"/etc/sudoers.tmp" XX lines, XXXX characters
press return to edit /usr/local/etc/sudo/sudoers.master:
visudo: can't stat /usr/local/etc/sudo/sudoers.master: Bad file number
И тогда visudo просто существует (код выхода 1).
Синтаксис для sudoers.master и appX.sudo файлы все проверить.
Что заставляет visudo не доводить дело до конца с открытием sudoers.master файл, который был включен через #include в конце базы sudoers?
Я наблюдаю такое поведение в AIX, Linux и Solaris.
В качестве обходного пути есть способ сказать visudo просто не следовать никаким #include директивы, и редактировать только основной файл?
Если вы используете #includedir скорее, чем #include visudo не будет пытаться редактировать включенные файлы, если в них нет синтаксических ошибок.