Intereting Posts
Почему tmux не подбирает переменные, полученные в моем tmux.conf? awk не будет использовать '||' как полевой разделитель Сжатие нескольких файлов в разных папках без структуры папок не удалось выполнить несколько команд на нескольких Linux-машинах? Не удается создать корневую тюрьму Fedora 16 не загружается после того, как Win7 установил GPT-диск Что означают «NO-CARRIER» и «DOWN» для беспроводного интерфейса? некорневой доступ к физическим блокам, занятым файлом Совместное использование папки / файлов несколькими пользователями на диске ext4 Для чего предназначен ENOANO (No Anode)? Есть ли патч ядра для предотвращения загрузки файлов в RAM для LiveCD? Лучший способ принять варианты «Да» из командной строки как распаковывать / распаковывать сегментированные zip-файлы? Входящий пакет не доставляется в сокет Изменение разрешений для файлов, созданных службой демона докеров

конфликт кэша паролей tee / sudo?

У меня большой скрипт bash (Ubuntu 12.04). Сценарий предназначен для вызова обычным пользователем; только определенные команды внутри скрипта работают с sudo. Невозможно запустить весь скрипт как root.

Внутри скрипта у меня есть много утверждений, похожих на них:

echo "blah blah" | sudo tee /path/to/file 

а также

 sudo tee /path/to/file > /dev/null << 'END' blah blah END 

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

Скрипт работает хорошо, и я не хочу его менять. На самом деле, я не хочу менять его вообще, потому что он отлажен и работает в производственной (сорт) среде.

Тем не менее, я хочу добавить лучший журнал. Поэтому я добавил следующие строки в начало моего сценария bash в соответствии с https://stackoverflow.com/a/11886837/463994

 #!/bin/bash >foo.log exec > >(tee -a foo.log) exec 2> >(tee -a foo.log >&2) 

Однако теперь, когда я запускаю скрипт, он запрашивает у меня пароль для каждого примера приведенных выше примеров команд sudo / tee (около 50 из них!).

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

Вот код, показывающий проблему:

 #!/bin/bash sudo -k >foo.log #truncate log file to start fresh exec > >(tee -a foo.log) exec 2> >(tee -a foo.log >&2) if [ -f fileone.txt ] ; then echo "sudo rm fileone.txt" sudo rm fileone.txt fi echo "sudo touch fileone.txt" sudo touch fileone.txt echo "sudo touch filetwo.txt" sudo touch filetwo.txt sudo touch /opt/file3.txt echo "blah blah" | sudo tee /opt/file3.txt sudo rm /opt/file3.txt exit 

Ожидаемый результат:

введите пароль один раз, и весь скрипт запускается

Фактический результат:

снова введите пароль для echo "blah blah" | sudo tee /opt/file3.txt echo "blah blah" | sudo tee /opt/file3.txt и любые аналогичные утверждения формы, приведенные в начале этого вопроса. Но только если используется код ведения журнала в начале скрипта. Без ведения журнала нет проблем.

У вас tty_tickets опция tty_tickets в вашей конфигурации sudo. Это значение по умолчанию. Этот параметр указывает sudo, что если вы аутентифицируете, набрав пароль на одном терминале, это подтвердит использование sudo на этом терминале.

Когда вы добавили эти перенаправления, sudo потеряло соединение с вашим терминалом. (Я думаю, sudo использует параметр PAM_TTY чтобы определить, на каком терминале он работает, я не знаю, как это определяется.) Когда вы сомневаетесь, sudo все время спрашивает.

Параметр tty_tickets полезен, если вы можете оставить сеанс tty_tickets регистрации на терминале где-нибудь, где случайный прохожий может попытаться запустить sudo для перехода из вашей учетной записи в root. Он не оказывает никакого воздействия даже на умеренно искушенных злоумышленников, которые могут насадить вредоносное ПО на ваш аккаунт и захватить при следующем запуске sudo. Таким образом, нет никакой реальной выгоды для этого варианта, это всего лишь помеха.

Чтобы отключить эту опцию, запустите visudo чтобы отредактировать конфигурацию sudo и добавить строку

 Defaults !tty_tickets 

Основываясь на ответе Джайлса, я придумал это исполнение его предложения:

Сначала создайте этот файл сценария:

 #!/bin/bash echo "Defaults !tty_tickets" >> $1 exit 0 

Во-вторых, включите это в основной скрипт, в начале:

 sudo grep -i "Defaults !tty_tickets" /etc/sudoers if [ $? -ne 0 ] ; then sudo chmod a+x $SRCDIR/install_scripts/no_tty_tickets.sh sudo -E EDITOR=$SRCDIR/install_scripts/no_tty_tickets.sh su -c visudo fi 

Он правильно редактирует / etc / sudoers. Вот результат:

 # # This file MUST be edited with the 'visudo' command as root. # ... # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL # See sudoers(5) for more information on "#include" directives: #includedir /etc/sudoers.d Defaults !tty_tickets 

Это работает и дает мне полное решение.