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?
Odpowiedzi:
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ą.
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?
zshnie powinno być, /usr/bin/jeśli jest źle zainstalowane. wszystkie muszle powinny znajdować się w/bin
/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).
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ć.
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.
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.
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.
bashi zshsą w/bin
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.
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.
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 zFBSDrozwidleniembournei niebash.