No tady je to fakt spis o preskocenem RTFM :-) To chovani je mozna blbe, ale to ze lidi bezhlave pousti nejake commandy na zaklade domenky, ci predpokladu - a nikoliv znalosti skutecneho chovani. Proste klasicke PEBKACe.
Ono driv slo zavolat beztrestne i rm -rf /
. Dnes uz se musite posnazit o trosku vic :-)
Přijde mi, co jsem četl, že systemd byl zpočátku vyvíjený především na rychlé spouštění/udržování kontejnerů/dockeru. I tahle služba (/home byl do ní přidán v r. 2015 - viz ten Lennartův commit s vysvětlením) je v tom směru. V dockeru není /home až tak zásadní adresář. Takže tehdy možná z tohoto pohledu název tmpfiles trochu smysl dával. Ale to už je dávno jinak...
A přesně proto každý normální vývojář věnuje hodně času, aby zabránil nechtěné ztrátě dat, takže admin musí u destruktivních akcí opisovat YES velkými, nebo dávat --really-force nebo podobné nápady, jak zabránit bezmyšlenkovitému odklepnutí.
Přístup smažu data, ani na to pořádně neupozorním, s odkazem na RTFM je učebnicový příklad psychopatie.
A přesně proto každý normální vývojář věnuje hodně času, aby zabránil nechtěné ztrátě dat
Já bych jen upozornil na to, že tohle je docela moderní věc. Vůbec nemá smysl z toho dělat amatérské psychiatrické diagnózy. Před 20 lety bylo naprostým standardem, že se příkaz na nic neptá. A to zejména příkazy pro experty (abych si půjčil výraz z jiné zprávičky). A ještě před pár lety byl v diskusích náhled ve smyslu "proč mě to otravuje se souhlasem, já vím co dělám".
Některé příkazy jsou zkrátka pro poučenější experty (ne obyč uživatele). Je tady příklad s rm -rf /
. Jasně, dneska mu musíte napsat referát o tom, proč opravdu potřebujete smazat roota a proč nepoužijete třeba cat /dev/zero > /dev/sda
.
Nemyslím že to je moderní (ve smyslu nová) věc. Spíš mi přijde že to souvisí s určitým "od-unixováváním" Linuxu. Standard před dvaceti lety... to byla zrovna z určitého pohledu trochu doba temna.
Unix Haters Handbook je letos třicet let starý. A příkaz rm má vlastní odstavce jako ilustrace toho, že "Unix abuses our trust by steadfastly refusing to protect its clients from dangerous commands" (a je to v kontextu lidí nucených na Unix migrovat ze systémů, které chránily).
21. 6. 2024, 10:22 editováno autorem komentáře
Unix Haters Handbook je letos třicet let starý.
Díky, staženo, přes horké letní večery si to snad přečtu.
Jinak k celému tématu. Díval jsem se do manu rm
na FreeBSD a žádné speciální potvrzení mazání čehokoliv tam prostě není. Přesto se kupodivu nestává, že bych si každý den 24x mazal /. Ve skutečnosti se mi to za celý unixový život nestalo ani jednou.
Unix abuses our trust by steadfastly refusing to protect its clients from dangerous commands
Ona je spíš otázka, na které vrstvě by ta ochrana uživatele měla být. Proto jsem dal příklad s tím cat
. Pokud si někdo bez rozmyslu hraje s low level příkazy libovolného OS, tak vždy narazí. A tedy dělat příklad na nějakém low level příkazu "vidíte, jak ten ten OS strašný" je dost nesmysl.
Přesto se kupodivu nestává, že bych si každý den 24x mazal /. Ve skutečnosti se mi to za celý unixový život nestalo ani jednou.
Tak pokud jste taky začínal s unixem před těmi 20 nebo 30 lety - nebo pod kontrolou - tak do vás hádám taky nacpali nějaké příčetné návyky. Pokud někdo přijde z Windows, nebo z mobilu, nebo dělá něco co by podle něj mělo jít snadno narychlo...
Ona je spíš otázka, na které vrstvě by ta ochrana uživatele měla být. ...
Pokud si někdo bez rozmyslu hraje s low level příkazy...
Obecně ano, ale v tomhle případě to spíš vypadalo na minimálně podceněnou a nekonsistentní dokumentaci než na hraní si úplně bez rozmyslu (ten co chybu hlásil man stránku četl *před spuštěním příkazu*).
Tak pokud jste taky začínal s unixem před těmi 20 nebo 30 lety - nebo pod kontrolou - tak do vás hádám taky nacpali nějaké příčetné návyky.
Ne, já jsem kompletní samouk.
A baví mě ty poznámky "pod kontrolou" nebo "nacpali". Ne. Vůbec. Jsou to dost zvláštní poznámky. Přece největší zábava je přijít si na to sám, zjistit, co je důležité (ne konkrétní věci, ale spíš postupy a způsob přemýšlení nad problémem) a dle toho se zařídit do budoucna.
Pokud někdo přijde z Windows, nebo z mobilu, nebo dělá něco co by podle něj mělo jít snadno narychlo...
No tak narazí. Což je zcela v pořádku. V tom je ta zábava. A v určité chvíli tu zábavu přetaví do profesionality.
Ve skutečnosti se mi to za celý unixový život nestalo ani jednou.
Mně se to nikdy nestalo tak, že bych si to přímo napsal, ale už se mi stalo, že jsem se překlepl v názvu proměnné. To se pak z "rm -rf ${TMP_DIE}/*" hodně rychle stalo prosté "rm -rf /*" a v kombinaci s tím, že se skript zavolal ze systemd při startu servicy to dokonalo své.
Mně se to nikdy nestalo tak, že bych si to přímo napsal, ale už se mi stalo, že jsem se překlepl v názvu proměnné.
A proč to bylo potřeba vůbec volat?
Tenhle příklad jsem čekal, tohle se probíralo na fórech mockrát, ale nikdy jsem nepochopil, proč někdo z nějakého obecného skriptu (typu systemd nebo rc-v init) má potřebu volat rm. Po jaké akci?
Kam tím směřuju. Každý program si má po sobě uklidit. Pokud něco vytvořil, tak ví, co vytvořil a pokud už to nebude potřeba, tak to prostě smaže. Konkrétní soubor, konkrétního jména na konkrétní cestě.
A ano, sám jsem v praxi viděl mnoho náhodných skriptů dělajících náhodné věci, ale vždy to ukazovalo na zanedbané řešení někde jinde.
Takže za mě, to že rm -rf
smaže nezálohované soubory ředitele vesmíru je konečně důvod tu věc opravit. Celou. Od základů. Což se mělo udělat už před mnoha lety.
toto je velmi limitovaný pohled na věc. Zcela opomíjí to, že ten program, co má po sobě uklidit je ten samotný skript.
rm -rf / jsem párkrát zkusil. Řízeně. A párkrát omylem jeho ekvivalent. A co... vyžral jsem si to do dna. Chybami se člověk učí... Ale je potřeba balancovat mezi voděním uživatele za ručičku jako neschopného idiota a ochranou před destruktivními omyly.
Ale toto je problém v návrhu aplikace samotné. Opravdu je /home/ adresář na dočasné soubory?
Tohle je nejaka obscese systemd porad neco uklizet.
1. Uzivatel si spustill screen a nechal bezet process ve screen-e. Odhlasil se a systemd mu pozabijel vsechny bezici procesy. Pokud Oracle admin nastartoval databazi, tak ji to sestrelilo v okamziku kdy se DBA odhlasil. Nejakou dobu se to resilo a nakonec se naslo "reseni". Uzivatelum s UID pod 1000 se procesy nezabiji.
2. Neubehnul ani rok a nekoho napadlo, ze by bylo dobre smazat vsechny shared memory segmenty po tom co se uzivatel odhlasi. A zase to same logout, crash databaze.
Unix Haters Handbook
Včera jsem to dočetl tak nějak do půlky a celkem by mě zajímalo, na kterých jiných OS ti lidé tehdy pracovali. UNIX byl drahý jako prase, oni určitě neměli doma ani počítač, na kterém by běžel a jiné OS byly pro veřejnost nedostupné. Takže tyhle příklady o lepším OS měli nejspíš ze své práce, kde měly nějaký soukromý tajný a dnes neznámý a neexistující OS.
A potom, už někde z počátku jsem zjistil, že jsem s tou knihou dost nekompatibilní. Jestli někdo považuje cp, rm, ls, mv za kryptografické názvy a prosazuje jména příkazů copy, delete, listdir, rename, tak v takovém os bych fakt nechtěl pracovat. V každém oboru existují zkratky a nejkratší příkazy jsou ty nejčastěji používané (alespoň v určité chvíli). Sám svoje prográmky pojmenovávám striktně na 3 písmena, protože víc se mi psát nechce. (A navíc mi to připomíná system shock 2, kde byly názvy levelů jako eng, med, sci ;-) Takže můj os vlastně připomíná horor :-D )
Mluvíme každý o něčem jiném. Považuji za zřejmé, že rm maže obsah adresáře předajného mu pozičním parametrem. Zatímco tahle libůstka leckoho překvapí, a mě by překvapila taky.
Že je něco vysvětleno někde hluboko v dokumentaci je hezké, ale dobrý návrh by neměl vyžadovat sáhodlouhé čtení, aby člověk předešel státě dat.
Že šlo rm ještě dál a implementovalo ex-post ochranu, s tim nesouvisí.