Плохо ли устанавливать оболочку root на что-то отличное от значения по умолчанию?


16

Однажды мой друг (который является опытным пользователем Unix / Linux) сказал мне, что установка оболочки root на что-то отличное от sh (то есть bash или zsh) может создать проблемы, потому что некоторые сценарии могут предполагать, что оболочка sh и делают что-то странное ,

Тем не менее, я думаю, что в Ubuntu по умолчанию установлена ​​корневая оболочка bash, и Gentoo также использует bash. Может кто-нибудь разрушить миф?

Ответы:


12

Да. Если во время загрузки происходит сбой системы, вы можете войти в корневую оболочку. Если у вас есть отдельный / usr, некоторые оболочки могут не запуститься успешно.

Я бы посоветовал создать учетную запись toor(uid 0, gid 0) с нестандартной оболочкой, а левый root с оболочкой по умолчанию.


Это случилось со мной, когда я обновил FBSD 7.2 до 8.0 и забыл восстановить bash. Я загрузился в однопользовательском режиме, чтобы исправить, но это работало только потому, что /bin/shвсе еще было связано FBSDс форком, bourneа не с bash.
gvkv

просто чтобы прояснить ситуацию, если я установлю, скажем, zshи как-то /usrповрежден, у меня будут проблемы? но моя система /bin/shуказывает на /bin/bashи bashсама, почему это не shповлияет?
phunehehe

1
По умолчанию root гарантирует, что система загрузится - руководство по обновлению по крайней мере позаботится о том, чтобы войти в систему как root. Однако это может быть не так для чего-либо еще. Решение состоит в том, чтобы дублировать учетную запись root с помощью оболочки не по умолчанию для повседневного использования и сохранять root как есть.
Мацей Пехотка

1
zshне должно быть, /usr/bin/если оно было установлено неправильно. все снаряды должны быть в/bin
ксенотеррацид

1
@xenoterracide: zsh на Gentoo включен, /binно сохраняет некоторые файлы /usr/share. Также я четко заявил, что проблема во время входа в систему во время загрузки (когда происходит сбой какой-либо службы).
Maciej Piechotka

7

Не должно быть проблемой.

Файлы сценариев оболочки явно кодируют, с какой оболочкой они выполняются. Он кодируется в первой строке, или другие программы или сценарии выполняют определенную оболочку и передают сценарий оболочки в качестве аргумента.

Единственная программа, о которой я могу думать, которая использует информацию оболочки учетной записи пользователя (помимо процесса входа в систему), это procmail. Действительно забавно, если ваш пользователь установил как shell / bin / false на почтовом сервере ... Но вы обычно не запускаете procmail от имени root.

Другим кандидатом могут быть строки в crontab root. Я не знаю, какова политика crond, какую оболочку использовать.


$ SHELL обычно устанавливается в / bin / sh crondaemon при запуске.
echox

3

Сценарии, написанные для оболочки Bourne, в большинстве случаев будут работать без проблем с BASH, ZSH или $ foo.

Во многих системах Linux не установлен оригинальный sh, вместо этого часто используется символическая ссылка на / bin / bash.

Если некоторые сценарии просто «предполагают», что оболочка явно sh, их следует переписать. Theres механизм shebang, чтобы выбрать, какой интерпретатор нужен вашему сценарию. Если это, сценарий должен включать #!/bin/shв качестве первой строки.

Настройки по умолчанию для вашей оболочки не должны быть релевантными в этом контексте.


2

Я не думаю, что изменение оболочки root может вызвать какие-либо проблемы. Кажется, я помню некоторые юниты (может быть, некоторые варианты BSD?) С tcsh в качестве оболочки по умолчанию для root.

Корень логины в любом случае редки. Как правило, вы входите в свою учетную запись, а затем su или sudo для root.

Важно то, что оболочка root должна иметь как можно меньше зависимостей, чтобы ее можно было использовать в контексте восстановления системы. Например, неплохо иметь статически связанную корневую оболочку; некоторые дистрибутивы поставляются со статически связанной версией bash или zsh или sash (оболочка со многими стандартными встроенными утилитами). Однако это не так важно, если ваша система может быть легко загружена с загрузочного компакт-диска или USB-накопителя.


По причине зависимости я думаю, что имеет смысл оставить оболочку как есть, чтобы большая системная модификация (например, обновление) не испортила бы все. Я согласен, что это легко исправить с помощью живого CD или USB, но мне не нужно было это исправлять.
phunehehe

1

Оболочка входа пользователя не влияет на процесс загрузки. Вы можете установить эту оболочку на то, что вы хотите. Не во всех системах есть bash, и они работают нормально. Также, если это /usr/bin/zshбыло установлено неправильно, все системные оболочки должны быть в /bin. Однако вам не следует менять /bin/shуказатель на что-то, отличное от значения по умолчанию (если вы не знаете, что делаете), поскольку многие сценарии #!/bin/shобычно указывают на bash, когда они должны это делать, #!/bin/bashпотому что они используют bashisms и другое поведение, которое не будет работать на zshили dash.


ой, извините, я допустил ошибку, на самом деле на моем компьютере оба bashи zshв/bin
phunehehe

0

У меня bash как оболочка по умолчанию для root. Некоторое время я использовал zsh , но потом вернулся к bash . Какую оболочку вы используете, не имеет большого значения.

Это проблема, только если несколько человек имеют root-доступ. В этом случае вы можете выбрать «общий знаменатель», обычно это bash, так как это наиболее широко используемая оболочка.


0

Что касается Solaris / Illumos, то здесь упоминается мини-FAQ по Solaris Root Shell.

Некоторые системные администраторы по-прежнему рекомендуют не изменять корневую оболочку в
системах Solaris. Спросите, почему, и вам могут сказать, что root нуждается в
статически связанной оболочке, которая не зависит от динамических
библиотек в / usr / lib. Это было верно в прошлом, но не
обязательно так сегодня. При правильной настройке Solaris похож на любую другую версию Unix и может поддерживать любую оболочку, которую вы определяете, для root или любой другой учетной записи.

Так что, да, если вы используете Solaris или Illumos, то лучше использовать и другие оболочки sh.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.