Od kiedy POSIX i GNU rm nie usuwają /?


23

Od kilku lat rmnarzędzie GNU nie usuwa, /chyba że zostanie wywołane z --no-preserve-rootopcją. Jednak polecenie rm -rf /to pozostawiono w zbiorowej podświadomości jako niebezpieczne od bardzo dawna, a ludzie wciąż często wymieniają je jako „przerażające” polecenie.

Zastanawiałem się, kiedy pojawiła się ta zasada, rmktórej nie można usunąć /. Sprawdziłem specyfikacje POSIX i widzę, że chociaż POSIX: 2008 zawiera tę funkcję bezpieczeństwa, POSIX: 2001 nie. Ponieważ wersje online specyfikacji POSIX są od czasu do czasu aktualizowane, z każdą nową wersją podrzędną sprawdziłem również maszynę do przywracania i znalazłem odpowiednią stronę POSIX: 2008 od 2010 roku i byłem w stanie potwierdzić, że reguła, rmktórej nie można usunąć /był już wtedy na liście.

Tak więc moje pytania to:

  • Kiedy reguła, rmktórej nie można usunąć, została /dodana do specyfikacji POSIX? Czy było to w oryginalnej wersji specyfikacji Single UNIX w wersji 4 z 2008 r., Czy zostało dodane w wersji?
  • Kiedy to ograniczenie zostało dodane do GNU rm? Jestem prawie pewien, że było to przed dodaniem go do POSIX, ale kiedy to się stało?


1
Powiązane: Interpretacja grupy Austin # 019 (2003), która opisała (ale nie wdrożyła) zmianę.
Michael Homer,

Odpowiedzi:


28

Wersję HTML wszystkich wydań POSIX 2008 można znaleźć online:

Zostało to dodane w edycji 2008.

Sprostowania techniczne na ogół nie dodają nowych funkcji.

Możesz zobaczyć, że poprzednia wersja ( http://pubs.opengroup.org/onlinepubs/009695399/utilities/rm.html ) (POSIX 2004) nie miała tego tekstu.

Nowy tekst został przyjęty na konferencji grupy austin 2003-05-09 do włączenia w późniejszej rewizji standardu.

Został o to poproszony przez Johna Becka z Sun Microsystems w marcu tego samego roku (link wymaga rejestracji w otwartej grupie, patrz także prośba o ulepszenie numer 5 tutaj ).

John Beck napisał w wtorek 11 marca 2003 r .:

@ page 820 line 31681-31683 section rm comment {JTB-1}

Problem:

Defect code :  3. Clarification required

An occasional user mistake, with devastating consequences, is to
write a shell script with a line such as:
      rm -rf $VARIABLE1/$VARIABLE2
or
      rm -rf /$VARIABLE1
without verifying that either variable is set, which can lead to
      rm -rf /
being the resulting command.  Since there is no plausible
circumstance under which this is the desired behavior, it seems
reasonable to disallow this.  Such a safeguard would, however,
violate the current specification.

Action:

Either extend the exceptions for . and .. on the noted lines
to list / as well, or specify that the behavior of rm if an
operand resolves to / is undefined.

GNU rmdodane --preserve-rooti --no-preserve-rootopcje w tym zatwierdzeniu 2003-11-09 , ale --preserve-rootstało się domyślnym tylko w tym zatwierdzeniu 2006-09-03 , więc w coreutils 6.2

FreeBSD zachowuje slash od czasu zatwierdzenia 2004-10-04 (z dziennikiem zatwierdzenia „Dowiedz się, jak ognioodporna jest moja bielizna” ), ale początkowo nie, kiedy był poniżejPOSIXLY_CORRECT , dopóki nie przypomnieli sobie, aby sprawdzić dekadę później, że POSIX jest teraz nakazując, w którym momencie zostało to zrobione również w trybie POSIX .

Pierwsze zatwierdzenie FreeBSD wspomina, że ​​Solaris już to robił.

@JdePB (w komentarzu poniżej) stwierdził, że link do poufnej informacji firmy Sun potwierdza i podaje więcej szczegółów na temat pochodzenia Solaris i sugeruje, że Solaris już miał zabezpieczenie, zanim zwrócił się do grupy Austin.

Wyjaśnia uzasadnienie dodania tego wyłączenia. Choć można winić tylko siebie, jeśli robią rm -rf /, jest to przypadek, w którym skrypt może to zrobić, jeśli robi rm -rf -- "$1/$2"bez sprawdzenia, które $1/ $2były dostarczane co jest rzeczą, która uderza trochę słońca klientom źle, kiedy niewłaściwe patch Solaris (zgodnie z tym linkiem).

Zakaz usuwania .i ..został dodany na długo przedtem, aby zabezpieczyć się przed potencjalnymi nieszczęściami. rmwciąż jest niebezpiecznym poleceniem. Robi to, co powinien: usuwać to, co mu powiesz.

rm -rf /*
cd /tmp &&  rm -rf .*/   # on some systems where rm -rf ../ still removes
                         # the content of ../ and shells that still
                         # may include . and .. in glob expansions.
rm -rf -- "$diretcory"/* # note the misspelled variable name
dir='foo '; rm -rf $dir/*

Usuwałby również wszystko. Wiadomo, że uzupełnianie nazw plików powłoki powoduje takie problemy

rm -rf someth<Tab>/*

Rozszerzony do:

rm -rf something /*

Ponieważ somethingtak się nie stało, że jest katalogiem.

Powłoki takie jak tcshlub zshdodadzą dodatkowy monit przy próbie połączenia rmza pomocą znaku *wieloznacznego ( tcshdomyślnie nie).



1
Jako młody spółdzielnia SA próbowałem skasować ukryte pliki w katalogu użytkownika na SunOS w / rm -rf .*z jego domowego katalogu . Niedługo potem wszystkie linie telefoniczne się zaświeciły ...
Aaron D. Marasco,

Stawiam $ rm -rf. * = Rm -rf / w zawiły sposób, aby się tam dostać.
Escoce,

@GuruAdrian na pewno * oznacza, że ​​wszystko pasuje tak. * = .Nazwa_pliku, ale również ../, a zatem ../ .. i ../../ .. ad infinatum, dopóki nie skończy się przestrzeń bitowa dla polecenia.
Escoce,

może w nowoczesnych skorupkach. Nie zawsze tak było. Opuściłem tę głębokość administracji i rozwoju systemu ponad 15 lat temu
Escoce,
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.