Czy złą praktyką jest ustawianie powłoki roota na coś innego niż domyślny?

16

Kiedyś mój przyjaciel (który jest doświadczonym użytkownikiem Uniksa / Linuksa) powiedział mi, że ustawienie powłoki roota na coś innego niż sh (tj. Bash lub zsh) może stwarzać problemy, ponieważ jakiś skrypt może założyć, że powłoka jest sh i robi coś dziwnego .

Myślę jednak, że Ubuntu ma domyślną powłokę root ustawioną na bash, a Gentoo również używa bash. Czy ktoś może obalić mit?

phunehehe
źródło

Odpowiedzi:

12

Tak. Jeśli system zawiedzie podczas uruchamiania, możesz zalogować się do powłoki roota. Jeśli masz oddzielne / usr, niektóre powłoki mogą się nie uruchomić.

Radziłbym utworzyć konto toor(UID 0, GID 0) z niestandardową powłoką, podczas gdy root pozostawiony z domyślną powłoką.

Maciej Piechotka
źródło
Zdarzyło mi się to, kiedy zaktualizowałem FBSD 7.2 do 8.0 i zapomniałem przebudować bash. Uruchomiłem się w trybie pojedynczego użytkownika, aby to naprawić, ale działało to tylko dlatego, że /bin/shwciąż było powiązane z FBSDrozwidleniem bournei nie bash.
gvkv
tylko dla jasności, jeśli zainstaluję powiedz zshi jakoś/usr jest uszkodzony, będę miał problem? ale mój system ma /bin/shwskazując /bin/bashi bashsobie, dlaczego nie będzie shmieć wpływ?
phunehehe
1
Domyślne „gwarancje” rootowania, że ​​system się uruchomi - przewodnik aktualizacji zadba o to, aby móc zalogować się przynajmniej do roota. Jednak może nie być inaczej. Rozwiązaniem jest zduplikowanie konta root za pomocą toor z domyślną powłoką do codziennego użytku i utrzymanie roota bez zmian.
Maciej Piechotka,
1
zshnie powinno być, /usr/bin/jeśli jest źle zainstalowane. wszystkie muszle powinny znajdować się w/bin
xenoterracide
1
@xenoterracide: zsh na Gentoo jest włączony, /binale zachowuje niektóre pliki /usr/share. Wyraźnie stwierdziłem również, że problem występuje podczas logowania podczas uruchamiania (gdy niektóre usługi ulegają awarii).
Maciej Piechotka
7

Nie powinno to stanowić problemu.

Pliki skryptów powłoki jawnie kodują powłokę, z którą są wykonywane. Jest zakodowany w pierwszym wierszu lub inne programy lub skrypty wykonują określoną powłokę i podają skrypt powłoki jako argument.

Jedyny program, jaki mogę wymyślić, który korzysta z informacji powłoki konta użytkownika (oprócz procesu logowania) to procmail. Naprawdę zabawne, jeśli użytkownik ustawił jako shell / bin / false na serwerze pocztowym ... Ale zwykle nie uruchamiasz procmaila jako root.

Kolejnym kandydatem byłyby linie w crontabie roota. Nie wiem jaka jest polityka crond, której powłoki użyć.

maxschlepzig
źródło
$ SHELL jest zwykle ustawiany przez crondaemon na / bin / sh podczas uruchamiania.
echox
3

Skrypty napisane dla powłoki bourne przez większość czasu będą działać bez problemów przeciwko BASH, ZSH lub $ foo.

W wielu systemach Linux nie jest zainstalowany żaden oryginalny sh, zamiast tego jest to często dowiązanie symboliczne do / bin / bash.

Jeśli niektóre skrypty po prostu „zakładają”, że powłoka jest jawnie sh, należy je przepisać. Istnieje mechanizm shebang, aby wybrać interpretera, którego potrzebuje twój skrypt. Jeśli to sh, skrypt powinien zawierać#!/bin/sh jako pierwszy wiersz.

Domyślne ustawienie powłoki nie powinno być odpowiednie w tym kontekście.

echox
źródło
2

Nie sądzę, aby zmiana powłoki roota spowodowała jakiś problem. Wydaje mi się, że pamiętam niektóre jednorożce (może niektóre warianty BSD?) Mające tcsh jako domyślną powłokę dla roota.

Loginy root są zresztą rzadkie. Zwykle logowałbyś się na własne konto, a następnie su lub sudo w celu rootowania.

Liczy się to, że powłoka roota powinna mieć jak najmniej zależności, aby była użyteczna w kontekście reparacji systemu. Na przykład dobrym pomysłem jest posiadanie statycznie połączonej powłoki roota; niektóre dystrybucje dostarczają statycznie połączoną wersję bash lub zsh lub sash (powłoka z wieloma wbudowanymi narzędziami). Nie jest to jednak tak ważne, jeśli system można łatwo uruchomić z ratunkowej płyty CD lub napędu USB.

Gilles „SO- przestań być zły”
źródło
Z powodu zależności uważam, że sensowne jest pozostawienie powłoki bez zmian, aby duża modyfikacja systemu (jak aktualizacja) nie zepsuła rzeczy. Zgadzam się, że łatwo to naprawić za pomocą Live CD lub USB, ale nie powinienem tego naprawiać.
phunehehe 24.10.10
1

Powłoka logowania użytkownika nie wpływa na proces rozruchu. Możesz ustawić tę powłokę na cokolwiek zechcesz. Nie wszystkie systemy mają bash i działają dobrze. Również jeśli jest /usr/bin/zshźle zainstalowany, wszystkie powłoki systemowe powinny być w nim /bin. Nie powinieneś jednak zmieniać /bin/shwskazań na coś innego niż domyślny (chyba że wiesz, co robisz), ponieważ wiele skryptów ma to, #!/bin/shco zwykle wskazuje na bash, kiedy powinny, #!/bin/bashponieważ powinny używać bashism i innych zachowań, które nie będą pracować nad zshlub dash.

ksenoterracid
źródło
Ups, przepraszam, że popełniłem błąd, właściwie na moim komputerze, oba bashi zshsą w/bin
phunehehe
0

Mam bash jako domyślną powłokę dla roota. Przez jakiś czas używałem Zsh , ale potem wróciłem do bash . Jakiej powłoki używasz, nie ma większego znaczenia.

To tylko problem, jeśli więcej niż jedna osoba ma dostęp do konta root. W takim przypadku możesz wybrać „wspólny mianownik”, którym zwykle jest bash, ponieważ jest to najczęściej używana powłoka.

polemon
źródło
0

W odniesieniu do Solaris / illumos wspomina Mini-FAQ o Solaris Root Shell

Niektórzy administratorzy nadal nie zalecają zmiany powłoki roota w
systemach Solaris. Zapytaj dlaczego, a powiedziano nam, że root potrzebuje
statycznie połączonej powłoki, która nie jest zależna od
bibliotek dynamicznych w / usr / lib. Tak było w przeszłości, ale
dzisiaj niekoniecznie tak jest. Solaris, jeśli jest poprawnie skonfigurowany, jest jak każda inna wersja Uniksa i może obsługiwać dowolną powłokę, którą zdefiniujesz, dla konta root lub dowolnego innego konta.

Tak, jeśli używasz Solaris lub illumos, możesz używać powłok innych niż sh.

gsl
źródło