У меня есть общий вопрос о сценариях системного администрирования, которые требуют, чтобы "некоторые" команды выполнялись с правами root, а другие - от обычного пользователя без полномочий root (например, myusername и т. Д.). Следует упомянуть, что я использую Ruby 1.8.6 в системе Linux Red Hat 4. Предложения, которые я видел до сих пор:
Мне стыдно, что я не понимаю эту тему лучше, но я немного удивлен тем, сколько «книг по сценариям» Ruby, на которые я ссылался, не касаются этого! Я предполагаю, что это больше похоже на никс, но кажется, что для чего-то существенного вы наверняка столкнетесь с этим.
Изменить: некоторые вещи, такие как mysql, я могу использовать параметры в команде, например --password, поэтому я использовал это для этого:
puts "Remote Password: "
system('stty -echo')
password = STDIN.gets.chomp
puts "Mysql Password (local): "
mysql_local_password = STDIN.gets.chomp
system('stty echo')
И затем я могу использовать эти пароли из сценария, но они никогда не отображаются в виде открытого текста. Но это, конечно, работает не для всех.
Еще я должен упомянуть, что есть команды, которые необходимо запускать от имени разных пользователей (помимо обычного пользователя root и одного обычного пользователя, может быть пользователь "build" и т. Д. И т. Д.)
Вопрос: Пожалуйста, помогите мне понять плюсы и минусы этих (и любых других предлагаемых или лучших решений). Кроме того, если есть исчерпывающая книга, ссылки, страницы руководства и т. Д., В которых рассматривается, как скрипты взаимодействуют с разрешениями базовой системы, к которой вы можете порекомендовать меня, это тоже было бы здорово.
Спасибо всем!
Да, вы можете использовать su для любого пользователя в скрипте как root, не требуя пароля. Это немного похоже на взлом, но он сработает. По пути у вас могут возникнуть проблемы (например, ваша среда меняется, когда вы выполняете su), но вы сможете заставить это работать. Я не думаю, что это «правильно». Кроме того, root может делать все, поэтому вы всегда можете найти способ делать все как root.
Я рекомендую использовать sudo для всего.
Для интерактивных материалов можно использовать sudo с запросом пароля. Я предпочитаю запрашивать у вас собственный пароль, а не пароль root. Таким образом, вы можете предоставить ограниченные права администратора, не сообщая пароль root (и, следовательно, полные привилегии). Необходимость ввода пароля хороша для ответа «эй! Я набираю свой пароль, это означает, что я делаю что-то потенциально опасное, давайте проверим, прежде чем я введу». Вы также можете настроить sudo так, чтобы он не запрашивал повторно пароль (т.е. после того, как вы его введете, вызовы sudo в течение n минут не будут запрашиваться).
Кроме того, вы можете сделать так, чтобы sudo позволял пользователю выполнять любой действие от имени root, а не просто ограниченный набор команд. Я использую это на ящиках, которые я админом; это лучше, чем «su -», дает вам некоторые возможности аудита из коробки, вы всегда можете «sudo -i» (или «-s», иногда), чтобы получить корневую оболочку и т. д.
Для неинтерактивных вещей выбор больше.
Я не очень люблю бинарные файлы suid. Это следует использовать только для очень часто используемых двоичных файлов, которым требуются привилегии root, а именно: очень простые и тщательно проверенные. ping, например, требует прав root для выполнения своей работы. Однако любой недостаток безопасности в двоичном файле suid потенциально очень опасен.
Использование ssh - очень сложный способ добиться этого.
Используйте sudo, настройте его так, чтобы пароль не требовался для определенных команд, требуемых скриптом. "man sudoers" читается долго, но определенно интересно - с sudo можно делать так много всего ...
Я бы выбрал №4:
Оставьте sudo для любых скриптовых команд, требующих root: system 'sudo rake ts: rebuild'
Вам не нужно слишком беспокоиться о повторяющихся запросах пароля; sudo кэширует тот факт, что вы прошли аутентификацию с помощью пароля на короткое время (по умолчанию около 5 минут. На странице руководства:
После аутентификации пользователя метка времени обновляется, и затем пользователь может использовать sudo без пароля в течение короткого периода времени (5 минут, если это не отменено в sudoers).
из man sudoers:
timestamp_timeout
Количество минут, которое может пройти до того, как sudo снова запросит пароль. По умолчанию - 5. Установите значение 0, чтобы всегда запрашивать пароль. Если установлено значение меньше 0, временная метка пользователя никогда не истечет. Это можно использовать, чтобы позволить пользователям создавать или удалять свои собственные временные метки с помощью sudo -v и sudo -k соответственно.
Таким образом, пока выполнение сценария займет <5 минут, пользователь должен увидеть только одно приглашение для ввода пароля - вообще ничего, если он недавно прошел аутентификацию.
Вы когда-нибудь заглядывали в такие вещи, как капистрано, кукольный, анзибль или повар для ваших задач?
Вы не упоминаете, каков объем вашей работы, поэтому я понятия не имею, могут ли они вам пригодиться.
Я бы избегал "суида" любой ценой. Нет смысла использовать его с установленным sudo, что кажется лучшим выбором для ваших требований к запуску команд с разными разрешениями / идентификаторами пользователей ('sudo -u user2 command2' и т. Д.).
Также вы можете запустить некоторые команды sudo без пароля в качестве разрешенных команд в сеансе ssh на основе ключей (ssh sshkeyaccessonlyuser @ yourhost 'sudo command'). Это может решить проблему кеширования, если вы не хотите иметь более длинные кеши паролей в sudo, и ваш скрипт не завершит выполнение команды sudo вовремя.
Я бы также выбрал sudo с решениями 1 и 5. Обратите внимание, что вы также можете использовать псевдонимы, чтобы сделать вашу установку более чистой, например:
Cmnd_Alias RUBY_TOOLS = /path/to/cmnd1, /path/to/cmnd2, etc.
Cmnd_Alias RUBY_TOOLS_NPW = /path/to/cmnd3
User_Alias RUBY_USERS = user1, user2, etc.
User_Alias RUBY_SPECIAL_USERS = root
RUBY_USERS ALL=(RUBY_SPECIAL_USERS) RUBY_TOOLS, NOPASSWD: RUBY_TOOLS_NPW
Правило ограничит доступ к командам RUBY_TOOLS как пользователям RUBY_SPECIAL_USERS и не будет использовать пароль для RUBY_TOOLS_NPW.
Судо очень гибкий. Вы также можете поиграть с Host_Alias, чтобы указать хосты, на которых будут применяться правила. Если вам нужно автоматизировать создание ваших правил sudo, вы можете использовать Авгий для этого.
Единственные недостатки этого метода, которые я вижу:
Один из способов решения второй проблемы - установить переменную SUCMD в вашей конфигурации и использовать ее перед всеми вашими вызовами exec. По умолчанию SUCMD будет sudo, но вы можете установить для него значение su позже, если вы хотите использовать другую систему, или просто ничего, если вы не хотите использовать SUCMD и настроить свою систему с setuid или групповыми привилегиями.
Хочу сказать, что, во-первых, я совершенно не знаком с Ruby, так как он кажется нетрадиционным языком для административных задач. Если посмотреть на варианты, перечисленные ниже, 5 кажется лучшим выбором. Если для какой-либо части вашего скрипта требуются права root, я бы сказал, что для запуска скрипта требуются права root.
Предоставляя все варианты, указанные выше, я не видел возможности запускать скрипт от имени пользователя root и просто запускать su username перед запуском команд от имени пользователя. Он имеет то преимущество, что не требует запроса пароля (не требуются права доступа к паролю как root), и он должен удовлетворить все ваши потребности.
Запустить скрипт от имени root, выполнить кучу задач от имени root, su newUser выполнить кучу задач от имени newUser, выйти (вернуться к пользователю root) выполнить еще несколько задач от имени root.
Здесь есть еще один метод, который я использовал время от времени. Если вам действительно не нужен пароль и вы не хотите зависеть от sudo, вы можете использовать сценарий suid-оболочки, который затем вызывает ваш сценарий. «sudo» имеет свои преимущества, но иногда его сложнее использовать, чем простую оболочку, например, из задания cron или как ЧАСТЬ другого скрипта.
Мне пришлось сделать это при обработке веб-журнала. Сценарий, запущенный от имени обычного пользователя, убирал файлы журнала с пути, затем он вызывал сценарий suid для отправки HUP в apache, чтобы он повторно открыл новые файлы журнала. Только HUP нужно было запускать с правами root, поэтому только эта часть была suid.