Сценарии, для которых нужен (немного) корневой доступ

Да, Вы можете su любому пользователю в сценарии как корень, не требуя пароля. Это - определенный взлом, но он будет работать. Вы могли бы икнуть по пути (Ваши изменения среды, когда Вы su, например), но Вы сможете заставить его работать. Я не думаю, что это "правильно". Кроме того, корень может сделать все, таким образом, можно всегда находить способ сделать все как корень.

Я рекомендую использовать sudo для всего.

Для интерактивного материала, sudo с подсказками пароля в порядке. Я предпочитаю, чтобы это предложило Вам Ваш собственный пароль, не корень. Таким образом, можно предоставить ограниченные административные права, не выдавая пароль корня (и таким образом, полные полномочия). Необходимость ввести Ваш пароль хороша для "эй! Я ввожу свой пароль, это означает, что я делаю что-то потенциально опасное, давайте проверим, прежде чем я введу". Можно также установить sudo для не запроса неоднократно пароли (т.е. после того как Вы вводите его, sudo вызовы в течение n минут не запрашивают).

Кроме того, можно заставить sudo позволить пользователю выполнить любое действие как корень, не только ограниченный набор команд. Я использую это на полях I администраторов; это более хорошо, чем "su - ", дает Вам некоторый контрольный материал из поля, Вы всегда можете "sudo-i" (или"-s", иногда) для получения корневой оболочки, и т.д.

Для неинтерактивного материала существует больше выбора.

Я не очень люблю suid двоичные файлы. Это должно использоваться только для очень наиболее часто используемых двоичных файлов, для которых нужны полномочия пользователя root, которые очень просты и которые полностью контролировались. ping, например, требует полномочий пользователя root сделать его работу. Однако любой дефект безопасности в suid двоичном файле потенциально очень опасен.

Используя ssh очень сложный способ достигнуть этого.

Используйте sudo, установите, он до не требует пароля для определенных команд, которых требует сценарий. "человек sudoers" является долгим чтением, но определенно интересный - существует так много материала, который можно сделать с sudo...

Я пошел бы с № 4:

Отпуск в sudo для любых команд в виде сценария, которые требуют корня: система 'sudo обстреливает ts:rebuild'

Вы не должны волноваться слишком много о повторных подсказках пароля; sudo будет кэшировать то, что Вы прошли проверку подлинности с паролем в течение короткого времени (приблизительно 5 минут по умолчанию. Из страницы справочника:

После того как пользователь аутентифицировался, метка времени обновляется, и пользователь может затем использовать sudo без пароля в течение короткого промежутка времени (5 минут, если не переопределено в sudoers).

от man sudoers:

timestamp_timeout

Число минут, которые могут протечь прежде sudo, попросит passwd снова. Значение по умолчанию равняется 5. Установите это на 0, чтобы всегда запросить пароль. Если установлено на значение меньше чем 0 метка времени пользователя никогда не будет истекать. Это может использоваться, чтобы позволить пользователям создавать или удалять свои собственные метки времени через sudo-v и sudo-k соответственно.

Таким образом, пока сценарий собирается занять <5 минут для выполнения, пользователь должен только видеть одну подсказку пароля - ни один вообще, если они недавно прошли проверку подлинности.

Я пошел бы 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.

Sudo очень гибок. Можно также играть с Host_Alias для определения хостов, на которые можно применить правила. Если необходимо автоматизировать поколение правил sudo, можно использовать Augeas для этого.

Единственные недостатки этого метода, который я вижу:

1. sudo требуется на (довольно очевидной) машине
2. необходимо назвать sudo, когда каждый раз Вы хотите, чтобы сценарий был выполнен

Один путь вокруг 2-го выпуска состоит в том, чтобы установить переменную SUCMD в Вашей конфигурации и использовать его перед всеми Вашими исполнительными вызовами. По умолчанию SUCMD будет sudo, но Вы могли установить его на 'su' позже, если Вы желаете пользователю другой системы, или только ни к чему, если Вы хотите не использовать SUCMD и установить Вашу систему с полномочиями группы или setuid.

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

Дайте весь выбор выше, я не видел опции запущения скрипта как корень и просто выполнение "su имя пользователя" прежде, чем выполнить команды как пользователь. Это обладает преимуществом не требования подсказок пароля (не нуждайтесь в полномочиях пароля как в корне), и это должно выполнить все Ваши потребности.

Запустите скрипт как корень, сделайте набор задач, поскольку корень, su newUser делает набор задач как newUser, выход (выходы назад пользователю root) делает набор больше задач как корень.

Существует другой метод здесь, который я время от времени использовал. Если Вы действительно не хотите пароля и не хотите зависеть от sudo, Вы могли использовать обертку suid сценарий, который затем называет Ваш сценарий. "sudo" имеет свои преимущества, но иногда более трудно использовать, чем простая обертка, сказать от задания крона или как ЧАСТЬ другого сценария.

Я должен был сделать это в своей обработке блога. Сценарий, работающий как обычный пользователь, был бы mv файлы журнала из пути, затем он назвал suid сценарий, чтобы отправить ПОНУКАНИЕ апачу, чтобы заставить его вновь открыть новые файлы журнала. Только необходимое ПОНУКАНИЕ для выполнения как корень, настолько только, что часть была suid.