Dlaczego Debian ustawia powłokę logowania użytkownika synchronizacji na / bin / sync?


14

syncjest jednym z kont użytkowników utworzonych przez samego Debiana. Zastanawiam się, dlaczego Debian ustawia powłokę logowania /bin/synczamiast na /bin/false. Jak Debian korzysta z tego konta użytkownika?

Odpowiedzi:


24

Jest to udokumentowane w /usr/share/doc/base-passwd/users-and-groups.txt.gz:

synchronizacja

Powłoka użytkownika syncto /bin/sync. Dlatego jeśli jego hasło jest ustawione na coś łatwego do odgadnięcia (np. „”), Każdy może zsynchronizować system na konsoli, nawet jeśli nie ma konta w systemie.

To naprawdę historyczny artefakt, nie spodziewałbym się, że syncużytkownik zostanie skonfigurowany w ten sposób w dzisiejszych czasach. W przeszłości użyteczne byłoby posiadanie takiego użytkownika, aby osoby posiadające fizyczny dostęp do konsoli ( np. W serwerowni lub w laboratorium pełnym stacji roboczych, jak na uniwersytetach) mogły zmniejszyć ryzyko utraty danych, gdy zamykanie systemu (aby odzyskać system po nieuczciwym procesie lub po prostu użyć stacji roboczej, jeśli został zablokowany przez poprzedniego użytkownika). Systemy uniksowe przed Debianem zwykle miały syncużytkownika i shutdownużytkownika, z którymi można właściwie zamknąć system bez znajomości roothasła. (Na naszych stacjach Sun SPARC po prostu STOPA boot...)

Warto zauważyć, jak wspomniał Peter Cordes , że w wielu systemach dostępne są inne mechanizmy zapewniające bezpieczne wyłączanie lub ponowne uruchamianie z konsoli bez możliwości uwierzytelnienia jako root: zdarzenia ACPI wywoływane przez naciśnięcie przełącznika zasilania (co prowadzi do czystego wyłączenia), lub CtrlAltDel(co prowadzi do czystego ponownego uruchomienia). AltSysRqmoże być używany w ostateczności do synchronizacji, zabijania, odmontowywania i ponownego uruchamiania, ale nie jest to czysty restart. Jak wspomniała JdeBP , posiadanie syncużytkownika to bardzo stary pomysł, którego początki sięgają przynajmniej wczesnych lat 80.


4
Użytkownicy nie powinni nic robić. Administratorzy mogą skonfigurować system w ten sposób, jeśli chcą. Kontekst historyczny jest tutaj istotny: w przeszłości, gdy syncużytkownik został dodany, kombinacje Alt + SysRq nie istniały, a system Linux był bardziej prawdopodobne, że jest gdzieś serwerem lub systemem współdzielonym w laboratorium, niż laptopem dla jednego użytkownika lub komputer stacjonarny. Przydatne było zapewnienie sposobu, w jaki ludzie z dostępem do konsoli mogliby bezpiecznie przygotować system na nieczyste zamknięcie, aby mogli ponownie uruchomić system bez dostępu do konta root, jednocześnie zmniejszając ryzyko utraty danych.
Stephen Kitt,

2
Warto zauważyć, że zamiast posiadania shutdownkonta instalowane są domyślne instalacje niektórych (wielu?) Dystrybucji Linuksa, tak aby ctrl + alt + f1 (aby dostać się do konsoli tekstowej na wypadek, gdyby obecny VT uruchomił graficzny ekran logowania) przez ctrl + alt + del wyzwala a shutdown -r nowlub równoważny. Tak więc fizyczny dostęp = możliwość uruchomienia czystego restartu, nawet bez SysRQ.
Peter Cordes,

1
@PeterCordes zauważa „Systemy uniksowe przed Debianem” - to jest przed 1993 rokiem ;-). Ale tak, w obecnych systemach są często inne sposoby robienia rzeczy bez użycia synclub shutdownużytkowników. (Aby być wyjątkowo wybrednym, wiele dystrybucji Linuksa ma obecnie DM na VT1. Niektóre nawet nie mają już tekstowych VT!)
Stephen Kitt

1
kiedy syncdodawano użytkownika ... Linux jako pomysł nie istniał. Konwencja ta przynajmniej sięga wczesnych lat 80.
JdeBP,

1
Trzeba pamiętać, że niektóre z tych systemów pochodzą z czasów sprzed „komputerów osobistych”. Jako taka synchronizacja może polegać na nagrywaniu na taśmę lub na innym strasznie wolno działającym nośniku, takim jak token ring, dyskietki. Jednocześnie systemy te były wystarczająco „kruche”, aby cykl zasilania mógł je uszkodzić. Jeśli więc Twój UPS mówi, że minie 5 minut do awarii, wyłączasz się i pomijasz synchronizację, aby nie zniszczyć maszyny wartej wiele milionów dolarów. Te problemy w dużej mierze już nie istnieją.
coteyr
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.