Vlákno názorů k článku
Včerejší výpadek Cloudflare nezpůsobil útok, ale konfigurační chyba od L. - Design, kdy když složba má omezenou velikost konfiguračního...

Design, kdy když složba má omezenou velikost konfiguračního souboru mi přijde ... zvláštní. Ale řekněme, že proto byly nějaké technickéí důvody. Nicméně pak bych si měl dát sakra majzla, abych nevygeneroval příliš velký soubor - je to vlastně stejný problém, jako kdyby ten soubor byl třeba syntakticky špatně.

Jasně, že po bitvě je každý generál a v praxi jsou věci složité a ne takhle jasné, ale stejně mi to přijde primárně jako problém SW architektury.

Technické dôvody sú dobré, pamäť je predalokovaná aby sa šetril výkon dokonca i na alokáciách.

Problém vznikol pri prepise kódu do Rustu, kde možnosť, že sa objekt nezmestí do pamäte bola síce ošetrená, ale len "korektným" pádom celého programu.

Design, kdy když složba má omezenou velikost konfiguračního souboru mi přijde ... zvláštní.
Já nechápu tohle divení se. Z podstaty věci je velikost souboru vždy omezená. Kdyby ničím jiným, tak dostupným místem. Rozdíl je jenom v tom, zda je to pevný limit, který je někde záměrně zadaný, validuje se a pokud možno je v dokumentaci. Nebo jestli je to limit, který plyne z okolností a může se v průběhu času měnit, třeba když ubyde místo na disku.

V tomhle případě to vypadá spíš na tu druhou variantu. Pokud je soubor vždy přibližně stejně velký, nebo třeba roste pomalu v čase s růstem sítě, dá se pochopit, že tam validace na vstupu není – protože správný soubor prostě bude vždy dostatečně malý na to, aby bylo možné jej zpracovat.

Ověřovat velikost souboru při generování samozřejmě může být jeden ze způsobů, jak validovat, že se generuje správně. Jenže když to budete navrhovat, nejspíš si řeknete „to by byla dost výjimečná chyba, že by se generování souboru pokazilo zrovna takovým způsobem, že by se soubor výrazně zvětšil“. Ostatně validace nějakého generátoru se budou zaměřovat spíš na to, že tam nějaká data nechybí nebo tam nejsou špatná data navíc. Validovat, že tam není něco duplicitně – co teď to asi Cloudflare do validací přidá, ale není to něco, s čím byste obvykle počítal hned od začátku. Zejména když by ty duplicitní záznamy nejspíš nevadily, kdyby jich nebylo moc.

Nejde o duplicitní záznamy, ty by samy o sobě ničemu nevadily. Šlo mi o to, že na straně konsumera byl nějaký constraint (velikost souboru), který nebyl kontrolovaný na straně producera.

Samozřejmě, když tam pošlu velký sobor (1 TB), tak to spadne tak jako tak, ale vygenerování tak velkého souboru je dost nepravděpodobné. Tady byl ale limit evidentně mnohem níž a jeho překročení časem pravděpodobné (a taky se to stalo).

Jenže na straně konzumenta nebyl záměrný limit. Na straně konzumenta to bylo řešené způsobem „do téhle paměti se to vždycky vejde“, protože se to tam vždy vešlo a velikost se neměnila. Překročení toho limitu nebylo pravděpodobné, a nestalo se to běžným růstem souboru (který snad běžně vůbec neroste). Ten soubor byl větší právě kvůli těm duplicitním záznamům.

Mimochodem, limit by měl v tomto případě stanovit producent, ten ví, jak mohou být data velká. Konzumenti se pak musí přizpůsobit.

Já souhlasím s tím, že nastavovat a kontrolovat limity je dobrá věc. Ale zrovna velikost souborů se omezuje málokdy, pokud to není z důvodu velikosti úložiště nebo to nejsou limity souborového systému. Zejména když jsou to interní soubory a ten soubor má nějakou svou přirozenou velikost, tj. nehrozí, že mi nějaký záškodník pošle obří soubor.