bin przez całe życie Linuksa nie było właściwie na nic.
Podobnie jak poziomy uruchomieniowe i initspawnowanie z gettypowodu rekordów /etc/inittab, binkonto było przestarzałe w świecie Uniksa, zanim nawet Linux został wynaleziony. Był to pomysł z lat 80., który został złamany przez wynalazek i przyjęcie NFS (Network File System) i jego nobodyużytkownika. Jego ciągła obecność w bazach danych kont użytkowników pod koniec 2010 roku, kiedy ludzie w komercyjnym świecie Uniksa aktywnie zaprzestali ich używania w latach 90., jest świadectwem bezwładności.
Pomysł polegał na tym, że binużytkownik posiadał różne katalogi, takie jak /bini /usr/bin(i rzeczywiście niektóre z innych wymienionych na /unix//a/448799/5132, takich jak /usr/mbini /usr/5bin) oraz niezidentyfikowany UID / non- pliki set-GID w nich. Posiadał również pliki i katalogi doco, takie jak strony podręcznika.
(W bardziej ekstremalnych przypadkach na niektórych Uniksach był nawet w posiadaniu /i /etc, chociaż ten ostatni był uznanym błędem w tworzeniu obrazu systemu operacyjnego SunOS. Ten pierwszy był po prostu niedorzeczny).
Zatem uprawnienie do wprowadzania aktualizacji oprogramowania, działającego jako użytkownik bin, nie było ogólnym uprawnieniem, działającym jako superużytkownik, do wykonywania jakichkolwiek działań przeciwko systemowi. Aktualizator oprogramowania nie mógł odczytywać / zapisywać prywatnych plików użytkownika, uzyskiwać dostępu do skrzynek pocztowych itp. które oczywiście może aktualizować oprogramowanie jako administrator.
Kilka innych specjalnych pozycji kont w twoim /etc/passwdpliku musi mieć hasła. Są to rachunki administracyjne - bin, daemon, sys, uucp, lp, i adm. […] Głównym powodem istnienia tych kont jest bezpieczne posiadanie poleceń, skryptów, plików i urządzeń. Niektórzy administratorzy instalują hasła do tych kont i faktycznie z nich korzystają. […] binKonto wolne od haseł jest niezwykle przydatne dla osób przerywających system.
- Rebecca Thomas i Rik Farrow (1989). UNIX Administration Guide for System V . Prentice Hall. ISBN 9780139428890. str. 452
NFS został wynaleziony na początku lat 80. i całkowicie złamał ten pomysł.
Było już na niepewnym gruncie, jak wspomniano w przytoczonym cytacie. Stało się tak, ponieważ możliwość aktualizacji plików obrazów programu dla podstawowych narzędzi, które superużytkownik wykonał jako przedmiot oczywisty, takich jak /bin/lsna przykład, jest bezpośrednim wektorem do uzyskania uprawnień administratora, a podział dostępu przy korzystaniu z binkonta po prostu zapobiegał przypadkowemu modyfikowanie niewłaściwych katalogów zamiast uniemożliwiać złoczyńcom uzyskanie dostępu administratora.
Nadejście NFS to podkreśliło. Chociaż system plików NFS miał mechanizm mapowania konta administratora na zwykłe konto użytkownika niesystemowego, nie działał tak samo dla kont innych niż root bin. Jeśli więc ktoś mógł uzyskać bindostęp do klienta NFS, dał mu bindostęp do plików systemu operacyjnego na serwerze NFS. W rzeczywistości umożliwił on superużytkownikowi klienta NFS, który w innym przypadku zostałby ponownie przypisany do zwykłego użytkownika niesystemowego na serwerze, aby uzyskać dostęp właściciela do plików i katalogów systemu operacyjnego serwera.
To była powszechna wiedza na początku lat 90., a wówczas otrzymywano mądrość od chownrzeczy, które należały bindo administratora, aby zatkać dziurę, która stała się już standardową pozycją raportowania w narzędziach kontroli bezpieczeństwa Unixa i była ostrzegana przed podobnie jak dokument instalacyjny Sendmaila.
Jeśli chodzi o pytania M. Hessa, pomysł ten nigdy nie został przyjęty w Debianie, który powstał dopiero po latach, gdy był znany jako zły pomysł w świecie uniksowym, który rzeczywiście wiedział, że jest zły, zanim powstał sam Linux zostało wynalezione. Systemy operacyjne BSD, których historia nie sięgają do 1980 roku już dawno zlikwidowane rzeczywistej własności, ale mimo to zachowują konta użytkownika w bazie danych konta. Na przykład konwertowany z FreeBSD bin: binwłasność na root: wheelwłasność już w 1998 r.
Dalsza lektura