У нас есть случай использования, когда s sh пользователь test2 получает разрешение на запуск определенного сценария, принадлежащего другому пользователю test3. Ниже приведены разрешения, предоставленные в файле /etc/sudoers.
test2 ALL=(test3) NOPASSWD: /home/test3/start.sh
Это хорошо работает, когда мы запускаем ssh test2@target_host sudo -u test3 /home/test3/start.sh
Мы хотели выполнить задачу s sh через ansible стать method:sudo и стать_пользователем, и это никогда не работает. мы обнаружили, что ansible изменяет инструкцию, как показано ниже, во время фактического выполнения, и это никогда не совпадает с разрешениями для файла sudoer.
sudo -H -S -n -u test3 /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-knavgwllrftljavwujkveyjcctlgkbda ; /usr/bin/python /var/tmp/ansible-tmp-1582478029.04-74694013835195/AnsiballZ_command.py'"'"'"'"'"'"'"'"' && sleep 0'"'"''
похоже, что наш единственный вариант - обновить разрешения, как показано ниже но этот тип дает полное разрешение оболочки на пользователя test3, который никогда не будет удовлетворять нашим требованиям безопасности
test2 ALL=(test3) NOPASSWD: /bin/sh
Кто-нибудь сталкивался с подобной ситуацией, как это раньше? для контролируемого исполнения. Обратите внимание, что test2 и test3 не являются пользователями sudo.