rm -rf /

Címkék

John Beck weblog-jában tűnt fel egy érdekes írás, amelynek címe: ``rm -rf /'' protection. Aki dolgozott már Unix(-szerű) rendszerekkel az tudja, hogy az ``rm -rf /'' parancs kiadásával a rendszer teljes pusztulását elő lehet (akár nem szándékosan, hanem véletlenül is) idézni.

(Kezdőknek: a ``/'' a root könyvtár, -f kapcsoló azt jelenti, hogy force, azaz felülbírál minden figyelmeztetést, a -r pedig azt jelenti, hogy rekurzívan töröl, magyarul addig, amíg az (leegyszerűsítve) egész filerendszert el nem távolítja)

A Solaris fejlesztők egy péntek délután olyan horror sztorikat meséltek egymásnak, amelyben az ``rm -rf /'' volt a főszereplő. Ekkor az egyikük feltette a kérdést: ``miért nem javítjuk ki az rm-et?''

John Beck megpatchelte az rm parancsot, amelynek ez lett a következménye:

#/bin/rm -rf /

#rm of / is not allowed

A Solaris 10 (a build 36-tól kezdve) már úgy fog működni, hogy sok-sok évnyi hagyomány után az rm paranccsal nem lehet majd a ``/''-t töröli.

``És ennek mi köze a FreeBSD-hez?''

Nézzük:Giorgos Keramidas-nak megtetszett a Solaris fejlesztők ötlete, és gyorsan meg is patchelte a FreeBSD rm(1) parancsot. A bejelentésből egy hosszú vita lett. Voltak akik nagyszerű ötletnek tartották a patchet, és voltak a fundamentalisták, akik szerint ez az ősi UNIX működés ellen való vétség, a UNIX különben sem Windows, és nem lenne szabad commit-olni.

A szerző szerint a patch-nek van értelme, hiszen elegendő véletlenül egy szóközt ütni egy amúgy biztonságos parancsban, máris kész a baj:

# rm -fr / home/someuser/*

Valaki egyetértett, mondván, hogy akár egy rosszul megírt cron job is okozhat katasztrófát. Valaki szerint az ``rm -rf /'' helyett lehetne használni a ``newfs'' parancsot. Volt aki nem értett egyet a dologgal, mondván, hogy a UNIX azért jó, mert ha ``lábon akarod magad lőni'', akkor azt is megteheted. Szerinte ha valaki biztonsági öveket akar építeni a FreeBSD-be, akkor azt tegye opcionálissá.

Más szerint már most is vannak ilyen biztonsági övek, például nem lehet newfs-t csinálni egy mountolt / partíción.

Volt aki szerint ezt nem az rm parancsban, hanem shell szinten kell megoldani. Egyelőre nincs döntés az ügyben.

A hosszú thread itt.

Neked mi a véleményed?

Hozzászólások

>> Neked mi a véleményed?

kiemelt felhasznalokent sokfelekeppen lehet "veletlenul" karokat okozni, miert pont ezen lovagolnak... a "rendszert" sztem senki nem sajnalja, 10 perc alatt vissza lehet huzni (ha nem, akkor azt az OS-t ki kell dobni), viszont egy adatbazisban kutyulas nehezebben detektalhato/visszaallithato, nagyobb karokat okozhat

> Neked mi a véleményed?

Nekem szimpatikus, hiszen egy hibalehetőséggel kevesebb.

Hi!

Szerintem ha valaki kiad egy rm -rf ./valami parancsot, akkor ott is eleg egy space. A patch nem old meg semmit.

Azellen nem véd. -- Szalacsi S.

By(t)e

TBS::Antiemes

ki mennyi modon tudja kiadni a fent citalt parancsot? :)

mindegyik ellen ved a patch? pl mit szolna egy rm -rf .* -hoz?

In true unix philosophy, we provide enough rope for you to hang yourself.

imho ezek NEM HIBÁK, hanem figyelmetlenségből eredő károk! a szoftver jól működik, csak az üzemeltetője nem! opcionális feature-ként viszont kiegészíthetők lehetnének az oprendszerek azzal, hogy az ilyen figyelmetlenségek elleni külön beállítható korlátozások vagy interakciók lépnének életbe...

A GNU coreutils-féle rm progiban van ilyen opció, kár hogy nem default.

Szerintem a dolgot egy kapcsoloval kellene inkabb megoldani. Igy alapban nem mukodne, akinek viszont kell, az meg aliasolna az rm-et.

Ugyanez a kötél jó lehet arra is, hogy a

villámkezűdzsó@localhost# rm -rf /

után le lehessen tesztelni mit ér a biztonsági mentés... :-)

Míg ha ugyanez nem lenne, akkor newfs-el kéne "szivatni magad":-) De azt meg mountolt fs-en nem csinálhatsz .........

Szóval imho kell az rm -rf / mint egy falat kenyér!

Különben mit mondanának a kezdő linuxosoknak, hogyan játszák le a .rm fájlokat? ;-)

A katasztrófák is ilyen apró emberi elnézések, figyelmetlenségek miatt történnek, tehát a rendszereket természetesen erre is méretezni/tervezni kell.

Tehát az, hogy egyetlen parancs kiadásával ilyen szintű pusztítást lehet véghezvinni, az nem fícsör, hanem komoly tervezési hiba.

> Tehát az, hogy egyetlen parancs kiadásával ilyen szintű pusztítást lehet véghezvinni, az nem fícsör, hanem komoly tervezési hiba.

Ez egyaltalan nem hiba. Ez egy tervezesi dontes, meghozza nagyon jo es bevalt.

Ha valaki az "alaprendszer" fole akar ilyesmi vedelmeket beepiteni, mert felti a felhasznaloktol es tevedeseiktol a gepet, akkor szerintem is kb shell szinten kellene megoldani.

Hat ez megint tipikusan annak a peldaja, hogy rontsunk el valamit ami mar regota jol mukodik. Ha kest adnak a kezedbe elvaghatod a kezed ha nem figyelsz. Ha kocsit adnak a kezedbe es nem figyelsz neki mehetsz egy fanak. En pl a sok ev alatt miota az rm-et hasznalom meg sose toroltem a teljes filerendszert vele. Ti eddig hanyszor toroltetek?

Ha meg meg is nagyon akarjak akkor defaultban mukodjon mint regen, es be lehessen allitani esetleg ha nagyon userfriendly kell akkor telepites kozben, ha nem akkor egy fileban az etc-ben, hogy akarod e.

> rm -rf .*

Hm. Mivel ez itt FreeBSD-ről szól, jobb ha tudod, legalább 5 éve nem megy fölfele a rekurzív rm

> cd / tmp/nemkell; rm -rf *

Rendes shell-ekben ha a cd több paramétert kap, kiabál. (Még rendesebbekben ez egy igen érdekes, de nagyon kevesek által kihasznált ficsor, hogy 2 paramétere is lehet a cd-nek..) Azaz legalább egy hibaüzeneted van, azaz valszeg a teljes takarítás előtt még tudsz nyomni egy ^C -t. Különben is, interaktív használatnál miért "cd;rm" és miért nem 2 különálló parancssor, amikor sokkal egyértelműbben nem futsz bele a problémába. ;-)

Amúgy meg igenis: MENTÉS!

Neeeee! Többek között azt szeretem a unix-ban, hogy nem akar okosabb lenni, nem akarja jobban tudni, hogy én mit akarok.

Pont erre vannak a jogosultságok: add csak ki userként az rm -rf /-t, és a rendszernek semmi baja sem lesz. A root meg (per definíció) _ért hozzá_, tőle meg nem szabad védeni. Ha meg mégsem ért, akkor tanulja meg! Elég elterjedt tendencia, hogy a usernek semmit se kelljen tudnia, majd a gép, de könyörgöm, most unix rendszergazdáról beszélünk, nem Manci néniről.

"Régebben a titkárnő kezelte a szövegszerkesztőt, most a szerkesztő kezeli a titkárnőt..."

Ja, egy kis lista, hogy mit 'kellene' még megelőzni:

http://www-uxsup.csx.cam.ac.uk/misc/horror.txt

Nem! Nem! Soha! Ne tegyek ezt be! Amellet, hogy jol fenekenbillenti a UN*X filozofiaat meg felesleges is. Volt itt valakinek egyaltalan ilyen problemaja? Nekem soha :)

Eloszor elegge nem tetszik, de en szivesen latnek egy ilyen featuret.

Sokkal jobb megoldasom van :), abszolut biztonságos, tuti!

alias rm='echo "Biztos benne(i/n)?"; read; if [ "$REPLY" == "n" ]; then echo "Na azert"; else echo "Megsem engedem"; fi'

esetleg

function rm()

{

for i in $*; do mv $i /Recycle Bin/; done

}

export rm

A fenti autós példából kiindulva:

Megteheted, hogy a kormányt használva elüss valaki. Tipikusan várható, hogy vezetés közben fogod a kormányt, ezért ez csak úgy tehető meg, ha direkt nekikormányzod valakinek.

Ellenben, ha könnyen melléléphetsz (mert rossz a pedálelrendezés pl.) akkor előfordulhat, hogy a fék helyett a gázra lépsz. Az ilyen félrelépések/félreütések kell védekezni. Az autóban megfelelő kialakítással ez megoldható. Sztem itt is.

Nem arról van szó, hogy korlátozni kell a root jogait, csak úgy kialakítani a rendszert, hogy egy elütés ne okozhasson katasztrófát.

Mondok egy másik példát: állománykezelő, navigálás könyvtárak között: egérrel kiválaszt, enterrel belép. Namármost, az enter mellett ott figyel a del. Ha lecsúszik a kezed, reszeltek a könyvtárnak.

Dettó ugyanez a szitu. Védekezni kell mindkettő ellen.