См. (Несколько) связанную тему Вот.
Некоторое время назад меня оскорбляли / высмеивали в сеансе IRC (как и следовало ожидать), потому что я вошел в систему как root для установки ruby.
По-видимому, это нормально * устанавливать службы, будучи корневым, но не службы для работы с учетной записью root. Это и понятно - вы не хотите, чтобы нарушения прав доступа, скажем, в apache разрешали привилегии root.
* что противоречит классным людям из IRC ... поймите.
Итак, главный вопрос, я думаю, заключается в том, почему инструкции по установке для многих служб (в последнее время видел их на nodejs, ruby и cloud9ide), предполагая, что вы не являетесь пользователем root при их установке?
Например, только на прошлой неделе я установил cloud9ide, но не смог заставить его работать, так как он специально запрещал мне запускать его как root. Однако об этом нигде ничего не упоминается. Я исправил эту проблему, выполнив:
su -s /bin/sh apache -c "node /var/www/cloud9/server.js -l 192.168.1.117 -p 3131 -w /var/www/html"
В дополнение к уже упомянутым причинам;
В среде, достаточно большой, чтобы иметь несколько системных администраторов для одного хоста или группы хостов, sudo допускает подотчетность, чего не делает совместное использование учетной записи root.
Как вы уже поняли, для некоторых вещей требуются привилегии root. Когда они вам нужны, вы должны их использовать.
Совершенно нормально использовать root, если вы знаете, какие команды будут делать, и что они не будут иметь никаких неожиданных побочных эффектов.
Скачивание программного обеспечения для Интернета и его компиляция потенциально опасно. Он может содержать ошибки или содержать намеренно вредоносные команды. Makefile может иметь rm -rf команда в нем, например. Или, возможно, в какой-то другой части скрипта сборки есть неизвестная ошибка, которая уничтожит вашу систему. Это же рассуждение может быть использовано, чтобы побудить вас не компилировать непроверенное программное обеспечение в производственных системах. Вы должны создавать и тестировать пакеты в тестовой среде, где это не имеет особого значения.
Вы можете следовать простому контрольному списку при использовании своих привилегий root. Если вы не можете ответить утвердительно на три из этих вопросов, вероятно, вам не следует использовать root.
Таким образом, на виртуальной машине, на которой вы только что сделали снимок, вы, вероятно, сможете обойтись без всякого разбора с вашими привилегиями root. На вашем рабочем сервере, на котором хранится множество критически важных служб, вам нужно быть более осторожным в использовании привилегий root.
Как и все, что связано с безопасностью, все зависит от уровня риска. Вы должны сделать разумное определение потенциального риска по сравнению с количеством усилий / вознаграждения. Есть места, где вам почти никогда не следует использовать root, а есть случаи, когда использование root для компиляции, вероятно, не связано с риском.
В инструкциях делается попытка предположить, что читатели должны следовать неявным «лучшим практикам», которые влекут за собой отказ от входа в систему как root.
У этих типов учебных пособий / инструкций есть часть своей целевой аудитории, которая просто копирует и вставляет команды или имеет достаточно знаний, чтобы создать настоящий беспорядок.
Важно научить новичков следовать этим передовым методам для их собственной защиты (и чувств, если они перейдут на IRC).
В этом отношении есть определенные вещи:
Каждый, кто использует root напрямую, будет жирно перетащить команду, и в какой-то момент это что-то сильно испортит. (Это не значит, что пользователи sudo неуязвимы, просто менее вероятно, и могут быть ограничения на такой ущерб).
Большинство пользователей, которые игнорируют передовой опыт и в конечном итоге начинают бездельничать, понятия не имеют, как исправить свой новый беспорядок.
Указанный пользователь, скорее всего, обратится к справочному форуму или каналу IRC с просьбой о помощи и, таким образом, будет высмеян за то, что в первую очередь является root.