Odzyskiwanie po ustawieniu powłoki roota na zły plik


23

Powiedzmy, że poszedłem i zrobiłem głupie rzeczy, takie jak użycie „chsh” do zmiany powłoki użytkownika root na złą ścieżkę pliku. Przyszłe logowanie do konta root nagle się nie powiedzie, powołując się na / bin / cokolwiek, co nie zostanie znalezione, i uruchomi się ponownie na ekranie logowania. Wyłączając tryb odzyskiwania lub wkładając LiveCD do edycji / etc / passwd, jakie są moje opcje odzyskania systemu? Załóżmy również (dla zabawy?), Że nie ma innych użytkowników w kole. Myśli?


Czy to hipotetyczna sytuacja, którą proponujesz?
Chris Down

Rzeczywiście zrobiłem dokładnie to na (stosunkowo świeżej) instalacji FreeBSD. Od tego czasu został ponownie zainstalowany, więc przypuszczam, że jest teraz nieco hipotetyczny, ale jestem ciekawy, jaka byłaby najlepsza droga do odzyskania, gdyby rzeczywiście był obecny cały system.
noffle

Byłem tam, zrobiłem to, mam koszulkę. Ale w rezultacie na każdym administrowanym przeze mnie komputerze utrzymuję zapasowe konto root, na wszelki wypadek.
Mark D

Odpowiedzi:


30

Podczas uruchamiania dołącz init=/bin/bash(lub ścieżkę do dowolnej innej powłoki funkcjonalnej) do opcji rozruchu - zostaniesz przeniesiony bezpośrednio do powłoki jednego użytkownika. Być może trzeba będzie to zrobić mount -o remount,rw /przed zmodyfikowaniem /etc/passwdwpisu w tym środowisku. Następnie po prostu uruchom ponownie lub zrób exec /sbin/init 3. Wystarczy zrobić nie wpisać exitlub naciśnij Ctrl + D, jak byłoby to spowodować panikę jądra *.

Jedna dodatkowa odmiana tej metody może być konieczna w niektórych systemach załadowanych w trybie dwustopniowym (z obrazem initrd). Jeśli zauważysz, że opcje rozruchu zawierają init=i, co najważniejsze real_init=, to miejsce do umieszczenia /bin/bashpowinno być drugim parametrem (tj real_init=/bin/bash.).

* Dzieje się tak, ponieważ w tym środowisku jądro postrzega powłokę jako program init - który jest jedynym procesem, który zna jądro - reprezentuje działający system pod okiem jądra. Nagłe zakończenie tego procesu, bez informowania jądra o zamknięciu systemu, musi spowodować panikę jądra. (Czy nie panikowałbyś, gdyby nagle wszystko wokół ciebie stało się czarne i milczące?)


Fajnie exec, ale chyba lepiej nie zepsuć wcześniej punktów montowania.
Stéphane Gimenez,

2
@ Steph Ty masz zrobić, że jeśli jądro nie zamontować korzeń odczytu i zapisu. W przeciwnym razie nie będziesz mógł modyfikować żadnych plików (w tym /etc/passwd).
rozcietrzewiacz

Dobre myślenie! Udało mi się przejść do trybu pojedynczego użytkownika, ale nie przyszło mi do głowy, że musiałem zamontować / as read / write, aby zmodyfikować / etc / passwd. Dzięki!
noffle

@roz Pewnie, próbowałem powiedzieć, że zajmę się odmontowaniem wszystkiego, co mogło być zamontowane (inne niż /) przed uruchomieniem init.
Stéphane Gimenez,

@ Stéph Nie powinno być problemów z mocowaniami. Zauważ, że /bin/bashjest uruchamiany dokładnie w punkcie, a następnie /sbin/initbędzie uruchamiany przy normalnym rozruchu. Dlatego w tym czasie system nie może wykonać żadnej możliwej akcji.
rozcietrzewiacz

10

Możesz użyć sui określić powłokę do wykonania (nie jestem pewien, czy próbujesz zasugerować, że nie jest to możliwe, gdy twoja notatka o braku innych użytkowników wheel):

su -c /bin/bash

W przeciwnym razie możesz zrobić coś podobnego, jeśli demon ssh pozwala na logowanie do rootowania:

ssh root@localhost /bin/bash

Możesz również ustawić powłokę jako init w bootloaderze, na przykład init=/bin/kshlub podobnym.


1
Dobre pomysły. =) Jak podejrzewasz, żaden inny użytkownik nie może używać „su”. sshd ma również wyłączone logowanie roota.
noffle 18.09.11

6

Jeśli twój program ładujący jest skonfigurowany tak, aby umożliwić edycję na żywo parametrów jądra, rozwiązaniem jest ponowne uruchomienie i użycie powłoki jako procesu inicjalizacji, np init=/bin/bash. Następnie zamontuj wszystko, co trzeba zamontować ręcznie, i edytuj /etc/passwd. synci uruchom ponownie ze zwykłym init.


Wow, właśnie zauważyłem, że
wysłałeś

6

Jeśli sedno twojego pytania polega na tym, że zablokowałeś wszystkie sposoby na rootowanie, z definicji nie możesz rootować.

Powszechnie dopuszcza się trzy sposoby rootowania w systemie uniksowym:

  • Zaloguj się jako root, wprowadzając rootpo zalogowaniu i wpisując hasło roota. To uruchamia powłokę roota.
  • Zaloguj się jako zwykły użytkownik, a następnie zrootuj się, uruchamiając sui wpisując hasło roota. W niektórych systemach wymaga to bycia w określonej grupie (często nazywanej wheel); w innych systemach każdy, kto zna hasło roota, może zostać rootem. Systemy używające PAM do uwierzytelniania używają pam_wheeldo zarządzania grupą kół, jeśli ją mają. Jeśli podasz polecenie za pomocą su -c, zostanie ono wykonane za pomocą powłoki roota.
  • Zaloguj się jako zwykły użytkownik, a następnie zrootuj się, uruchamiając sudoi wpisując własne hasło. Konto użytkownika musi otrzymać uprawnienia sudo od administratora. O ile nie jest to ograniczone w sudoerspliku, możesz uruchomić dowolne polecenie, niezależnie od powłoki roota.

Tradycyjnym sposobem ochrony przed niedostępnością powłoki roota jest zdefiniowanie innego konta z UID 0 i inną powłoką ( toorto tradycyjna nazwa). Na przykład, jeśli powłoka roota jest dynamicznie połączonym plikiem wykonywalnym (dobrym pomysłem, aby zaoszczędzić pamięć), a aktualizacja biblioteki pójdzie nie tak, powłoka roota może być bezużyteczna. Alternatywne konto root miałoby statycznie powiązany plik wykonywalny, prawdopodobnie z wbudowanymi typowymi narzędziami, takimi jak BusyBox .


5

Powyższe odpowiedzi są świetne i nauczyłem się z ich czytania. Jeśli nie pamiętasz szczegółów tych podejść i nie masz nic przeciwko ponownemu uruchomieniu, zawsze możesz uruchomić system za pomocą dystrybucji CD na żywo, zamontować partycję /, a następnie edytować / etc / passwd i zrestartować komputer. Nie tak eleganckie jak powyższe rozwiązania, ale łatwiejsze do zapamiętania.


Należy zwrócić uwagę na ryzyko związane z ręczną edycją /etc/passwdpliku. Poza tym, dobra uwaga - chciałem tylko dodać tę samą sugestię do mojej odpowiedzi.
rozcietrzewiacz
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.