Автоматический ввод пароля sudo из скрипта.

man sudoers.

Да блин, скрипты то даже тупым друзьям кидаю. Поэтому мне нужно тупо в скрипте

Не надо так делать. Добавь возможность выполнения определенной команды через sudo без пароля.

А как тогда работают эти программы для ввода пароля sudo, по типу gksudo

Они же sudo как то пароль передают

Используют системную библиотеку.

Если в скрипте хочешь ввести пароль, можешь взять expect. Но его обычно по умолчанию в системе нет - надо ставить.

Используют системную библиотеку.

А тут вот поподробней

И тут

можешь взять expect.

1) sudo читает пароль не из stdin а из контролирующего терминала, для его имитации есть какие-то проги

2) sudo - плохо, избавься от него

3) ты что-то делаешь совсем неправильно, даже если закрыть глаза на п.2, что именно нужно то на самом деле?

тупым друзьям

Интересный ты друг…

Поэтому мне нужно тупо в скрипте

А почему бы весь скрипт через sudo не запускать?

А как тогда работают эти программы для ввода пароля sudo, по типу gksudo

Почитай у sudo про опцию -A (–askpass).

sudo -S echo -n 2>/dev/random 1>/dev/random

whata…

Что ты вообще пытаешься сделать?

Используют системную библиотеку.

А тут вот поподробней

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

man expect покажет, как им пользоваться.

Но как уже выше говорили - это неправильный подход. Правильно - дать права на команду в sudoerc.

N.B.: Говорят же, что арч даёт глубокое понимание системы...

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

А в python вроде как нельзя сишные библиотеки инклудить, хотя он на C написан, и даже вроде как библиотеки под него можно на c писать

А теперь не vbox запустить спокойно и не сделать программу

без -n работает. арч.

Секунду, проверю

РЕАЛЬНО! Ну пока что ещё поговорим про библиотеки

N.B.: Говорят же, что арч даёт глубокое понимание системы…

а есть примеры дистрибутива которые учат использовать sudoers и не одобряют sudo?

Есть! Это debian XD

import sh

password = 'password'

with sh.contrib.sudo(password, _with=True):
    print(ls("/root"))

Я такую дичь нашёл, скрипт на пайтоне, буду тестить, смотреть что внутри)

Не надо так делать

Почему?
Для чего тогда вообще сделали параметр ‘-S’?
Просто спрашиваю. Интересно.

Почему?

$ echo 'pa$$w0rd' | sudo -S -p"" cat -
$ echo 'pa$$w0rd' | sudo -S -p"" cat -
pa$$w0rd

В случае если sudo закешировало авторизацию и не будет спрашивать пароль - он попадет вызываемой команде в стандартный ввод.

Хранить пароль открытым текстом в скрипте - идея плохая. (хотя не факт что ТС это делает)

Хранить пароль открытым текстом в скрипте - идея плохая.

Да это то понятно.
Но есть же временные вещи, типа kdialog –password и т.п.
И в чем прямо вот опасность?

И в чем прямо вот опасность?

То что пароль может попасть в stdin недостаточно?

типа kdialog –password

Так можно и SUDO_ASKPASS использовать.

Вообще, когда я писал первый комментарий, у меня было ощущение что ТС не осилил отредактировать /etc/sudoers и, вместо того чтобы разрешить без пароля выполнять определенные команды, делает скрипты в которых пишет пароль открытым текстом.

Но я не могу придумать сценарий при котором стоит использовать sudo -S в скрипте.

То что пароль может попасть в stdin недостаточно?

Ну вообще … не знаю.
Ну попал, ну скрипт в фоне отработал и всё.

Но я не могу придумать сценарий при котором стоит использовать sudo -S в скрипте.

Вот. Отсюда и мой вопрос выше про нужность ‘-S’

Есть сценарий, если тебя задолбало вводить пароль, даже короткий. Ну а в целом то я хочу сейчас повторить на пайтоне pkexec. Юзал на дебиане те скрипты, щас просто копался в них и нашёл пару скриптов с этой строкой.

ДОСТАЛИ СО СВОИМ /etc/sudoers, ну давайте покукарекайте, если я юзаю кучу дистров, мне удобней их скопировать и закинуть.

Ну попал, ну скрипт в фоне отработал и всё.

Именно! И я не пойму, что опасного запускать vbox и systemctl start vbox-что-то_там от рута. Это мой скрипт же, не какого то плохого человека

sudo - плохо, избавься от него

Почему?

Оно вносит путаницу в чёткую систему разделения прав между администратором и пользователем и таким образом вредит как безопасности, так и просто чистоте системы. Главным образом - в головах новичков, его использующих. У них создаётся ложное впечатление о неких «повышенных правах» запуска программы (которых не существует), в целом почти полный аналог виндузятского «запустить от админа». Основной сценарий её использования - совершенно идиотское и неприемлемое «у меня что-то программа не работает, кажется прав не хватает, добавлю их» (иногда без «кажется» и без предварительной проверки, но дела это не меняет). Среди её функций есть проверка разрешённых/запрещённых действий, но: 1) она сделана методом текстового анализа команды... 2) обычно оно не настроено, ибо так сделано что настраивать не хочется, и эта тема тому подтверждение.

При правильном же использовании это чисто избыточный дубликат su, но спрашивающий почему-то не тот пароль, который нужно.

Есть сценарий, если тебя задолбало вводить пароль, даже короткий

Так поставь kali linux Впрочем там уже тоже non-root пользователь появился по умолчанию…

ну давайте покукарекайте

echo "%sudo ALL=(ALL:ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/sudo-nopasswd

Позиция ясна, спасибо за ответ

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

в «рассовоправильном» su для его использования использующему необходимо знать пароль root :) по мне так самая главная дыра su в случае когда все необходимо допускать непривилегированного пользователя до некоторых привилегированных функций.

в «рассовоневерном» sudo имеется куча разграничивающих средств в sudoers, позволяющих дать возможность пользователю запускать четко ограниченные root-овые функции под четко ограниченным пользователем (ты наверн в мане до такого даж не дочитывал) зная лишь только свой пароль.

как говорится почувствуй разницу.

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

Проблема с sudo, мне кажется, в том, что с его помощью слишком легко преодолеть любые ограничения. Если запускаемая через sudo программа имеет возможность писать в файлы, особенно произвольные файлы, или умеет форкать дочерние процессы, то мне кажется, что её будет достаточно несложно использовать, чтобы получить полный доступ к системе.

Теоретически, например. Мы даём пользователю sudo доступ к mount, и пользователь делает bind mount /etc, заменяя /etc/passwd и /etc/shadow на свои.

Да, можно наверное разрешить только mount со строго определенными аргументами, но кто поручится, что в большом sudoers нет каких-либо похожих возможностей?..

теоритически совершил глупость ты, а не sudoers :).
не подумавши, дал пользователю неограниченный доступ.
это в принципе и есть стандартная ошибка «запустить от администратора», которую указали чуть выше.

практически надо создать скрипт с четкими параметрами, что куда монтировать, к примеру «mount /dev/sdb2 /тра/ля/ля …»
запретить пользователю его менять и дать доступ на исполнение данного скрипта через sudo.
и профит… пользователь имеет четко ограниченный доступ к привилегированному функционалу.
на ум приходят еще несколько вариантов, чуть более замороченных.

sudoers дает только те возможности, которые прописаны его правилами. коль ты не разбираешься в составлении правил, то ты с большой вероятностью их сделаешь кривыми.
но это проблема не инструмента, и она не решаема ни одним методом кроме четкого понимания как работать данным инструментом.
и эта проблема есть не только в ИТ :) сколь народа молотком по пальцам попадало.

Нет, всё не так. sudo как раз заточен на неправильное использование, и практически непригоден для правильного. Его правильное использование, как я уже писал, полностью перекрывается su, и то оно дефективное из-за того что спрашивает не тот пароль.

по мне так самая главная дыра su в случае когда все необходимо допускать непривилегированного пользователя до некоторых привилегированных функций

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

в «рассовоневерном» sudo имеется куча разграничивающих средств в sudoers,

Эти «средства» сделаны ужасно костыльным способом. Нельзя так делать.

ты наверн в мане до такого даж не дочитывал

Ты глупый?

пользователю запускать четко ограниченные root-овые функции

Вот функции и надо ограничивать. sudo это не умеет. Зато, сюрприз, это умеет делать ядро с начала времён с помощью setuid-бита прав на программе, реализующей разрешённую функцию (не идиотский текстовый фильтр на команду! именно программа которая делает то что нужно). Или, для некоторых, чуть более современные capabilities.

практически надо создать скрипт с четкими параметрами, что куда монтировать, к примеру «mount /dev/sdb2 /тра/ля/ля …»
запретить пользователю его менять и дать доступ на исполнение данного скрипта через sudo.

Ну вот, уже лучше. Осталось только заменить скрипт на программу и выкинуть sudo, поставив программе setuid root.

sudoers дает только те возможности, которые прописаны его правилами. коль ты не разбираешься в составлении правил, то ты с большой вероятностью их сделаешь кривыми.

Правила, основанные на строковых операциях, априорно дефективны.

Его правильное использование, как я уже писал, полностью перекрывается su

Ну и как такое через su делать?

zabbix ALL= (ALL) NOPASSWD: /opt/zabbix/zabbix_mdraid.sh

Или предлагаешь suid-обертки делать?

Предлагаю. Не обязательно обёртки кстати.

Я так понимаю речь про это: https://github.com/linuxsquad/zabbix_mdraid/blob/master/zabbix_mdraid.sh

Этой портянке однозначно пойдёт на пользу переписывание на нормальный компилируемый язык. Кстати, автор, такой нехороший человек, ещё и #!/bin/bash туда всунул. Однозначно переписать.

Я так понимаю речь про это

Как пример.

Этой портянке однозначно пойдёт на пользу переписывание на нормальный компилируемый язык.

И это утверждение можно экстраполировать на все shell-скрипты? А интерпретируемые языки «ненужны»?

ещё и #!/bin/bash туда всунул

У меня есть только догадки о причинах возмущения:

• использование bash, вместо sh
• нелюбовь к shebang
• страсть к /usr/bin/env

Хотите сказать что sh лучше, чем bash?

Не понял, только что работало, сейчас не работает

И это утверждение можно экстраполировать на все shell-скрипты? А интерпретируемые языки «ненужны»?

Нет, не на все. Где-то и обёртка сойдёт. Но вобщем-то sudo как раз такой обёрткой и получается, так что бояться их не надо, а вот вместо текстово-ориентированного списочного конфига дать права на конкретный файл - вполне хорошо.

У меня есть только догадки о причинах возмущения:

1) использование баша 2) и это несмотря на то, что в скрипте кажется башизмов нет 3) расширение всё равно оставим .sh чтоб всех запутать 4) ну и да, без env оно не кроссплатформенно, а ведь можно было просто написать /bin/sh, впрочем даже с env кому-то придётся ставить лишний баш (нет конечно, просто шебанг пропатчат)

Чуваки, ну cкрипт то мне уже нафиг не нужен, но как тогда сделать что-то вроде pkexec на пайтоне?

Как быть с группами, пользователями и аргументами?

Группе adm я хочу дать возможность пускать одни программы, группе support - другие. А группе web я хочу дать возможность выполнять часть команд, но от пользователя www-data, а не от рута. А если я хочу дать права на выполнение команды только с определёнными аргументами? И всё это вместе и в перемешку. Setuid тут не справляется.

Но вобщем-то sudo как раз такой обёрткой и получается

Совершенно верно. Ты предлагаешь написать ещё миллион обёрток под каждый отдельный случай вместо использования универсального sudo.

Что вы мне мозги своим sudoers пудрите? Я может быть ещё пишу на пайтоне pkexec. Лучше скажите как передать в пайтоне это

Как быть с группами, пользователями и аргументами?

В чём проблема? Ну и повторю: то, как проверяет аргументы sudo (с помощью сравнения строк) - никуда не годится. Проверять надо осмысленные сущности, а не строковое их представление.

Группе adm я хочу дать возможность пускать одни программы, группе support - другие.

Ты не поверишь:

$ ls -al /usr/sbin | grep rws
-rwsr-xr--  1 root dip    408644 янв  7  2021 pppd

А группе web я хочу дать возможность выполнять часть команд, но от пользователя www-data, а не от рута.

Аналогично.

А если я хочу дать права на выполнение команды только с определёнными аргументами?

Аргументы должна проверять алгоритмическая обёртка. И не с помощью сравнения строк или регулярок на командную строку, а с помощью парсинга argv[] аналогично той программе, которую запускаешь и дальнейшего моделирования того, что произойдёт. А ещё она может сама их составить из более простого собственного синтаксиса (ведь если ты хочешь ограниченную функциональность то незачем синтаксис от полной тащить).

Совершенно верно. Ты предлагаешь написать ещё миллион обёрток под каждый отдельный случай вместо использования универсального sudo.

Универсально-костыльного. Такая универсальность не нужна.

Я pkexec у себя удалил ещё раньше чем sudo, так что с этим помочь не могу, кроме как отговорить с ним связываться.

Передать что? Пароль? Я в первом комментарии сказал - используй expect(или соответсвующий модуль для питона).

Дак я хочу попробовать написать pkexec просто для практики.