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

expect можно запустить одной комманой? Типо expect command(Например echo test)

Ты не поверишь, но все аргументы командной строки передаются всем программам как строка, которую потому эта программа парсит. Ты предлагаешь в каждой обёртке дублировать этот функционал. Для управления правами нам достаточно белого листа на список аргументов. Для того, чтобы разрешить ls -l dirname мне не нужно анализировать, что делает ключ -l, достаточно только добавить этот ключ в наш белый список и выставить ограничение на количество аргументов. С твоим подходом обёртка будет реализовывать часть внутренней логики программы. Ты предлагаешь написать ещё более переусложнённый SELinux.

Далее, группы. Группа adm должна запускать команду от пользователя admuser, группа web от пользователя www-data. Какие права надо выставить на эту команду с твоим подходом?

Unix - это не свалка костылей и подпорок. Это стройная, логичная система костылей и подпорок. (с)

Пока что ты предлагаешь только более запутанные костыли.

expect реализует мини-скрипт. Ты пишешь, что ожидаешь увидеть на вводе и передаёшь ему ответ.

# Код по памяти, не проверенный.
user=username
password=userpass
expect {sudo password for $user: }
send $password

ок

ls -l dirname мне не нужно анализировать, что делает ключ -l,

А если юзер захочет ls -l --sort=size ? А если ls --sort=size -l ? А если ещё какой незначимый флаг всунет? А если там есть опасные, которые надо запретить? А если ему можно делать ls только на поддиректории пути /ls_sandbox/ и при этом там внутри могут быть симлинки наружу? Разумеется, тупым текстовым сравнением все эти случаи не покрыть, и будет очередное убожество по типу «вот тут это нельзя потому что наш кривой инструмент так не умеет».

С твоим подходом обёртка будет реализовывать часть внутренней логики программы.

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

Ты предлагаешь написать ещё более переусложнённый SELinux.

Он тут ни причём и ни разу не похож.

Группа adm должна запускать команду от пользователя admuser, группа web от пользователя www-data

chown admuser:adm adm_program && chmod 4750 adm_program chown www-data:web web_program && chmod 4750 web_program

Если хочешь чтобы одна и та же команда так работала (что весьма странное требование, ну да ладно), тогда делаешь suid-root, внутри getuid() и по результатам setgroups(), setgid(), setuid().

Unix - это не свалка костылей и подпорок. Это стройная, логичная система костылей и подпорок. (с)

У тебя - может быть, а мне нравится когда не костыли а нормальный софт.

А это писать куда? В интрепритатор expect или в bash?

# Код по памяти, не проверенный.
set user ""
set password ""
expect {\[sudo\] пароль для $user: }
send $password

Вот правильный вариант кода, но он почему-то не работает(Я юзера указал и пароль)

Ааа, понял

Или не понял, почему не работает.

set user "я юзер"
set password "мой парольчик"
spawn sudo echo test
expect {\[sudo\] пароль для  $user: }
send $password  

без env оно не кроссплатформенно

Недавно в каком-то треде обсуждали что и env не везде есть.

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

Да. И вполне удобной оберткой. Зачем мне делать обертку на компилируемом языке, если мне нужно просто дать возможность запускать пару стандартных утилит с фиксированными аргументами? Мне куда удобнее засунуть команду их в .sh и выдать через sudoers на него права.

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

Есть несколько админов администрирующих один сервер. Иногда кто-то добавляется, иногда кто-то удаляется. Они все должны знать рутовый пароль? После каждого удаления администратора рутовый пароль надо сбрасывать?

enot_obrmot

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

Просто есть системы где bash отсутствует.

если мне нужно просто дать возможность запускать пару стандартных утилит с фиксированными аргументами?

Если аргументы фиксированные то незачем их каждый раз набирать, они должны быть зашиты в обёртке.

Есть несколько админов администрирующих один сервер. Иногда кто-то добавляется, иногда кто-то удаляется. Они все должны знать рутовый пароль? После каждого удаления администратора рутовый пароль надо сбрасывать?

Спрашивать собственный пароль это то же самое что не спрашивать никакого.

Как раз один рутовый пароль на всех - это проходной двор. Судя по этому и предыдущему комментам, ты исключительно про локалхост говоришь. Городить громоздкие обёртки для каждого приложения, в обход пакетного менеджера бинарники копипастить с разными именами, кастомные права выставлять, одним паролем на всех пользоваться и т.д. Это не работоспособно в реальных условиях и требует слишком много ручной работы. Если ты сможешь подобную систему написать и предоставить прототип хотя бы с настройками для base-system утилит, можно посмотреть. А пока что это всё очень похоже на обрастающую всё большими и большими костылями здоровую помойку.

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

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

любое незнакомый инструмент работает непонятно :) новичок незнакомый как с работой su так и sudo накосячит и там и там :)

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

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

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

коль с твоей стороны это правильно, давай быстренько сгенерь прогу пот заданию в первом сообщении:) а мы посмотрим.

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

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

У тебя - может быть, а мне нравится когда не костыли а нормальный софт.

почему же ты не написал свою систему, в которой весь софт правильный с твоей точки зрения ??
если ты думаешь что *никс и его философию писали дураки, то ты сильно ошибаешься.

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

Ты о чём вообще? Хватит теоретизировать.

Если ты сможешь подобную систему написать и предоставить прототип хотя бы с настройками для base-system утилит

Какой прототип? Там нечего писать, всё уже есть. Вместо графомании с написанием бесполезных утилит ради утилит лучше заняться чем-то полезным.

Какие теории? Ты сам выше по треду на мои вопросы предлагаешь проводить манипуляции с бинарниками и писать обвязку над каждой утилитой с использование внутренней логики самих утилит.

этож opensource с открытым кодом. Патч.

Ты собрался избирательно выдавать права на echo и grep что ли? не неси чушь. Речь шла про те случаи, где надо непривилегированному юзеру дать способ запустить что-то привилегированное. Таких случаев МАЛО и никаких «каждых утилит» там явно нет. А вот вменяемая (никакого бреда типа регулярок на командную строку) обработка аргументов необходима.

ты еще не написал компилируемую прогу по условиям топик стартера.

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

ты еще не написал компилируемую прогу по условиям топик стартера.

Я и не собирался. Топикстартер хочет какую-то муть и не может нормально объяснить зачем.

а дальше…

Прекращай бредить. У тебя представления о работе ИТ-систем из какого-то подвала 90-х.

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

скрипты то даже тупым друзьям кидаю

Избавься от тупых друзей.

тупо в скрипте

Себя тоже замени (по гарантии).

А это обидно было

А это обидно было

«Этта ЛОР, детка!» © Chelobaka

☺

А если серьёзно, то хранить пароль плейнтекстом — крайне хреновая идея!

А если серьёзно, то пароль — крайне хреновая идея!

Copyleft Richard Stolman

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

Да. Но нет. Но да.