Dlaczego NIGDY nie należy edytować pliku / etc / shadow?

W innej odpowiedzi tutaj na UNIX & Linux Stack Exchange Michael D Parker napisał , w odpowiedzi na to, że ktoś powiedział, że takie postępowanie jest „bezpieczne”, że:

Zwykle NIGDY nie należy edytować pliku / etc / shadow.

Więc:

Dlaczego nigdy nie należy edytować /etc/shadowpliku bezpośrednio?

Istnieje kilka powodów, aby nie edytować /etc/passwd, /etc/shadow, /etc/group, /etc/gshadowlub /etc/sudoersbezpośrednio, ale raczej używać vipw, vigrlub visudo:

• Jeśli popełnisz błąd składniowy, możesz nie być w stanie zalogować się lub zostać rootem. Korzystanie z narzędzi viXXX zmniejsza to ryzyko, ponieważ narzędzie dokonuje kontroli poprawności przed modyfikacją pliku.
• Jeśli plik jest edytowany jednocześnie, ktokolwiek zapisuje ostatni, nadpisze zmiany wprowadzone przez poprzednie edycje. Obejmuje to zarówno administratorowi edycję pliku i plik jest modyfikowany, ponieważ użytkownik o nazwie passwd, chshalbo chfnzmienić coś na temat swojego konta. Jeśli użyjesz odpowiedniego narzędzia, zapobiegnie to jednoczesnym modyfikacjom. Jest to głównie problem w systemach z wieloma użytkownikami, w mniejszym stopniu, jeśli jesteś jedynym użytkownikiem.
• W niektórych systemach (głównie lub tylko * BSD) vipwaktualizuje wiele plików (np. /etc/passwdI /etc/master.passwd). Nie dotyczy to Linuksa.
• vipwautomatycznie tworzy kopię zapasową ( passwd-, shadow-...), co jest przydatne, jeśli uświadomić sobie, że przypadkowo usunięte linię. Przydaje się to tylko wtedy, gdy zdajesz sobie sprawę przed następną edycją, więc nie zastępuje kontroli wersji i kopii zapasowych, ale może być bardzo przyjemne, jeśli szybko zdasz sobie sprawę z błędu. visudonie robi tego

Państwo może edytować plik bezpośrednio. Będziesz po prostu podejmował dodatkowe ryzyko bez prawdziwej przewagi.

Są na to zasadniczo dwa sposoby:

1. Nigdy nie edytuj niektórych plików bez użycia zalecanych narzędzi, ponieważ prawdopodobnie nie wiesz, co robisz, i to jest w porządku, ponieważ te narzędzia wiedzą lepiej i są zawsze dostępne.

2. Mówiąc bardziej realistycznie, równie dobrze możesz go teraz zepsuć, gdy zastanawiasz się nad tym, abyś mógł z wyprzedzeniem zaplanować kopię zapasową i porównać różnice po wykonaniu, ponieważ podstawowa wiedza na temat tajników podstawowego loginprocesu początkowego twojego systemu jest prawdopodobnie warta mając na to, kiedy złamiesz to w inny sposób później, a wspomniane narzędzia ci nie pomogą.

Chyba możesz powiedzieć, które polecam. Mówię, że jeśli temat Cię interesuje choćby przez chwilę, równie dobrze możesz wykorzystać tę ciekawość i zdobyć nowe umiejętności, gdy jesteś przy nim. Zwłaszcza jeden, takich jak to - shadowplik jest w dość podstawowym formatem, i co nieco wiem o tym dowiedziałem się po zerwaniu go przypadkowo - i nie było to wynikiem edit zrobiłem do tego pliku.

Raczej mój problem pojawił się po innym błędzie z bazą danych zarządzania pakietami, która doprowadziła menedżera pakietów do zastąpienia go bez zapisywania kopii zapasowej i wszyscy użytkownicy w systemie zostali kaput . Dalsze nieświadome nieudolne próby naprawienia spowodowały jedynie uszkodzenie innych powiązanych plików i nie trzeba było długo czekać, aby przywrócić większość /etcplików tekstowych z (mniej aktualnej niż oczekiwano) kopii zapasowej.

Gdy to zrobiłem i sprawdziłem, czy mam to w stanie sprawnym, postanowiłem celowo, skrupulatnie zrobić to wszystko jeszcze raz. I jeszcze raz. To było kilka miesięcy temu, ale dzisiaj jestem pewien, że mogę zdiagnozować źródło loginproblemu z jednorazowym pojedynczym plikiem dziennika w moim systemie i rozwiązać go za pomocą dowolnego edytora podstawowego (i zapewne rzucił okiem lub dwa at man 5 problem_file) zapewniały tylko podstawowy dostęp do uszkodzonego systemu plików root. Nie został tanio uzyskany - zajęło mi to większość dnia - a powiązane pliki konfiguracyjne są rozrzucone po całym katalogu (a nawet niektórych - takich jak Linux PAM /var/run/no_login- na innych mountach) - ale było warto. A przy odrobinie przemyślenia mogłoby to być tańsze.

Morał z tej historii jest to, że prawdopodobnie nie jest dobrą rzeczą, że format krytycznych configs jak shadow, passwd, groups, shellspowinno być tak nieprzejrzysty nam, że musimy zatrudniać specjalnych narzędzi edycyjnych, które mogą lub nie mogą poprawienia naszej pracy w sposób iw z powodów, dla których nie rozumiemy jedynie prostej zmiany. Myślę, że przynajmniej warto poświęcić chwilę, aby dokładnie zrozumieć, co zrobiliby inaczej niż my.

To prawdopodobnie jest dobrą rzeczą, jednak, że kiedy zapoznają się wystarczająco z edycji powiedział pliki ryzykujemy dokonywania w nich a potem zapisywania ich typograficzne lub proste błędy składniowe, że istnieją narzędzia, którymi dysponujemy, która może dokładnie sprawdzić naszą pracę w sposób i z powodów, które już rozumiemy przed zastosowaniem naszych zmian blase.

Kontrapunkt - jeśli trzeba skopiować zestaw loginów użytkowników z jednego serwera na drugi, nie znając ich aktualnych haseł ani nie przypisując im nowych, wówczas należy bezpośrednio edytować plik / etc / shadow, aby wstawić pole z hasłem. vipw nie pozwala dotknąć tego pola, to tylko „*”

Aktualizacja: lub w tym przypadku użyj chpasswd -e „hashowane hasło”, ale można to zrobić tylko bezpośrednio na komputerze. Jeśli pracujesz z zestawem plików, które nie zostały jeszcze wdrożone na maszynie (np. Maszynie wirtualnej), bezpośrednia edycja może być Twoim jedynym rozwiązaniem.

tzn. Zwykle jest narzędzie do robienia tego, co chcesz zrobić bez bezpośredniej edycji / etc / shadow, wystarczy wiedzieć, co to jest ...

Innym powodem, dla którego musisz edytować te pliki jest to, że edytujesz pliki w obrazie systemu plików, które będziesz uruchamiać w innym systemie, i musisz debugować ten system po uruchomieniu. Na przykład eferemalny system plików MAAS używany w przypadku niepowodzenia uruchamiania lub w trybie ratunkowym.

Nigdy nie mów nigdy ... chyba że masz na myśli.