Должен ли я использовать «sudo» в сценариях, которые я пишу?

Я настраиваю новую машину (ну, на самом деле, Ubuntu VM) и пытаюсь написать скрипт, чтобы настроить несколько общих вещей, которые я использую при этом (Git, curl, vim + janus).

Поэтому мой сценарий выглядит примерно так:

#setup #!/bin/sh sudo apt-get install git sudo apt-get install curl ... 

Не похоже, чтобы «sudo» смешался с моей командой – это просто мое показное чувство безопасности. Кажется, что что-то вроде следующего может также работать:

 sudo setup 

Есть лучший способ сделать это? Каковы ваши эмпирические правила при написании сценариев и необходимы повышенные разрешения?

3 Solutions collect form web for “Должен ли я использовать «sudo» в сценариях, которые я пишу?”

В сценариях нет проблем с использованием нескольких вызовов 'sudo'.

Я нахожу это лучше, чем запуск всех скриптов с правами root, поскольку риски ограничены ограничением повышения привилегий командами, которые им действительно нужны.

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

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

Я бы сказал, нет. Нет, если у вас нет веских оснований. Я работаю в большой финансовой компании с очень строгими правилами безопасности, поэтому одна из вещей, которые мы делаем, – это отнять у всех судо, а затем отбирать ее выборочно.

Один из идентификаторов, которые мы убираем, – это root. Это означает, что если я устанавливаю RPM с «sudo rpm …», я делаю это как root, но это нормально, но если этот RPM, то в его скриптах пытается sudo, он потерпит неудачу – потому что, снова , мы заблокировали даже корень из глобального sudo.

Теперь, если мы, случаем, выборочно предоставили sudo для определенных команд, может случиться, что если 100% вызовов sudo RPM – это то, что было предоставлено root. Но шансы этого малы.

У нас были проблемы с sudo внутри скриптов RPM. Лучше просто оставить это, я думаю. Или, по крайней мере, имейте в виду, что есть такие компании, как моя, где вы можете не знать, кто имеет права для чего, и даже root может не иметь этого.

  • Как я могу построить fdupes из источника на Ubuntu?
  • Как установить определенную версию reiserfsprogs?
  • Флаги pkg-config являются относительными
  • Windows 8.1 не загружается на моем ноутбуке с двойной загрузкой
  • Обратный "lvconvert --splitcache"?
  • Упаковка приложений Windows с вином в формате deb и rpm
  • Устройство Raid5 имеет меньше пространства, чем ожидалось
  • Как я могу обмениваться подключением к Интернету между двумя компьютерами Linux, используя FireWire с Ubuntu 14.04?
  • Не удается apt-get - проблема с установкой пакета
  • Как узнать, какая система драйверов X11 используется?
  • Iptables не переадресует. Вместо ввода
  • Interesting Posts

    Как начать процесс выскочки для приложения golang?

    Не удалось запустить Gnome System Log Viewer после настройки фильтров

    Скрыть события активности при запуске

    Поверните консоль при запуске (Debian)

    Что означает значение #: 3 в команде оболочки

    как привязывать каждый интерфейс к отдельной конфигурации VPN

    Есть ли способ остановить остановку и через X секунд снова запустить систему?

    Можно ли изменить команду для `cd`, чтобы отображать только каталоги и игнорировать файлы?

    Имитировать chroot с unshare

    Как я могу найти используемый по умолчанию (шрифт) ресурс XTerm?

    Короткое чтение при попытке открыть / dev / sda2

    Предотвращение завершения экрана GNU после завершения сеанса завершения сеанса

    grep print относительный путь к файлу при выполнении рекурсивного поиска

    ошибка установки oracle 11g на Ubuntu 17.04 Mate

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

    Linux и Unix - лучшая ОС в мире.