Jaderné noviny – 15. 12. 2011: Řešení desítky let známého útoku přes /tmp

27. 12. 2011 | Luboš Doležel

Články - Jaderné noviny – 15. 12. 2011: Řešení desítky let známého útoku přes /tmp  

Aktuální verze jádra: 3.2-rc5. Citáty týdne: Ingo Molnar, Greg Kroah-Hartmann. Bernat: Ladění linuxové route cache pro IPv4. Řešení útoku přes symbolické odkazy.

Obsah

• Aktuální verze jádra: 3.2-rc5
• Citáty týdne: Ingo Molnar, Greg Kroah-Hartmann
• Bernat: Ladění linuxové route cache pro IPv4
• Řešení útoku přes symbolické odkazy

Aktuální verze jádra: 3.2-rc5

Aktuální vývojová verze jádra je 3.2-rc5 vydaná 9. prosince. Trvalo to něco přes týden a bohužel musím oznámit, že -rc5 je větší (alespoň co do počtu commitů – většina commitů je dost malá, takže je možné, že *diff* bude nakonec menší, ale nekontroloval jsem to) než -rc2 i -rc4. Tolik k 'uklidňování'. Od -rc4 bylo začleněno 355 změn, což je zajisté více než u -rc2 (280) a -rc4 (207), ale méně než u -rc3 (412). Dohromady bylo od -rc1 1254 změn, což je při něco přes 10 % z celku relativně málo.

Stabilní aktualizace: 9. prosince vyšly stabilní verze 2.6.32.50, 3.0.13 a 3.1.5. Všechny tři obsahují obvyklý dlouhý seznam důležitých oprav.

Citáty týdne: Ingo Molnar, Greg Kroah-Hartmann

Začal jsem používat Gnome 3.2 na svém hlavním desktopu před 4 týdny a ačkoliv jsem do toho šel s předsudky a očekával jsem, že to bude nelehké, všechno je zatím překvapivě fajn.

Ve skutečnosti je to nejlepší (myšleno nejpoužitelnější, nejintuitivnější) linuxový desktop, co jsem pro vývoj jádra a procesy spojené s jeho údržbou kdy používal. Nepřekáží mi, snaží se být tam, kde jej potřebuji a bere ergonomii používání a konzistenci UI tak vážně jako Apple a Google. Chvála.

-- Ingo Molnar

Tvá další sada patchů by měla raději mít správně napsané položky v soupisu změn, které popisují to, co patche vlastně dělají, měla by být řádně očíslovaná (žádný hovadiny jako 30/30 po řadě 00/29), neměla by rozbít kompilaci (opravdu chci příliš?), měla by se aplikovat bez okolků a na závěr by tomu vypomohla domácí vánočka tvého výběru, hlavně aby byla čerstvá a nebyly v ní sušené kousky ovoce (namočené v likéru by nevadily.)

-- Greg Kroah-Hartmann

Bernat: Ladění linuxové route cache pro IPv4

Vincent Bernat zaslal dlouhý popis toho, jak funguje cachování rout v IPv4 a jak to poladit pro co nejlepší výsledky. Jakmile byla do cache rout přidána položka, existuje několik způsobů, jak ji odstranit. Většina položek je odstraněna garbage collectorem, který prochází route cache a odstraňuje neplatné nebo staré položky. Bude spuštěn, když se route cache zaplní nebo v pravidelných intervalech, jakmile je dosaženo určité hranice. (Děkujeme Paulu Wisovi).

Řešení útoku přes symbolické odkazy

Problémy se symbolickými odkazy jsou tu s námi už po desítky let, za tu dobu byly dobře pochopeny a vývojáři dostali jednoznačný návod, jak se jim vyhnout. Přesto jsou tu stále s námi a nové zranitelnosti se pravidelně objevují. Je znám způsob, jak se většině problémů vyhnout pomocí úpravy jádra – což je něco, co se už po mnoho let dělá v grsecurity a openwall – ale nikdy se to nedostalo do hlavní řady. Zatímco jaderní hackeři pochopitelně nejsou moc nadšení z vytváření jaderných obezliček pro rozbité programy v uživatelském prostoru, tento konkrétní problém je natolik závažný, že asi dává smysl to udělat. Vypadá to, že se v tomto směru začíná něco dít.

Základní problém je chyba mezi momentem kontroly a použití (time-to-check-to-time-of-use; TOCTTOU). Rozbité aplikace ověří přítomnost nebo vlastnosti dočasného souboru před jeho otevřením. Útočník může využít chyby změněním souboru (často vytvořením symbolického odkazu) mezi kontrolou a open(). Pokud má program s chybou vyšší oprávnění (např. setuid) a útočník nahradí soubor odkazem na systémový soubor, může se objevit vážný problém.

Tato chyba se obecně děje ve sdílených, všem zapisovatelných adresářích s nastaveným sticky bitem (jako /tmp). Sticky bit je nastaven, aby bylo uživatelům zabráněno mazat soubory jiných uživatelů. Takže oprava omezuje schopnost následovat odkazy ve sticky adresářích. Především je symbolický odkaz následován jen v případě, kdy je vlastněn tím, kdo následuje, nebo pokud adresář a odkaz mají stejného vlastníka. Toto řeší většinu problémů se symbolickými odkazy na systémové soubory, aniž by se porouchaly nějaké známé aplikace.

Na patche omezující následování symbolických odkazů jsme se dívali v červnu 2010. Od té doby se objevil dvojí přístup vedený Keesem Cookem ve snaze dostat kód do hlavní řady. Prvním je Yama LSM, jehož cílem je sesbírat rozšíření modelu nezávazného řízení přístupu na Linuxu [Linux discretionary access control; DAC]. To ale naráží na obvyklý problém se specializovanými LSM: nemožnost kupit LSM na sebe.

Cook a jiní by ale jistě raději viděli změny v symbolických odkazech v hlavním kódu VFS než přes LSM, ale někteří se snaží věc udržet mimo tento hlavní kód. O Yama a jeho ochraně symbolických odkazů proběhla diskuze u kulatého stolu LSM na Linux Security Summitu, kde se zrodil plán protlačovat Yama jako LSM vylepšující DAC. Možná to nemá zavřené dveře, nicméně Cook zaslal patch, který umisťuje omezení symbolických odkazů do fs/namei.c

Posledně jmenovaný patch vyvolal nějaké zajímavé komentáře, ze kterých by se dalo soudit, že Ingo Molnar a Linus Torvalds v zamezení problému alespoň vidí smysl. Žádný z vývojářů VFS se do diskuze při tomto průchodu nepřipojil, ale Cook upozorňuje, že patch zohledňuje zpětnou vazbu od Al Vira, což by se mohlo brát jako znamení, že není úplně proti. Molnar byl obzvláště nerad, že tato díra stále existuje:

Uff – a již vyřešená návrhová vada VFS, které se dá předejít a dá se opravit, je nadále zneužívána.

Molnar měl také nějaké otázky ohledně implementace, včetně toho, zda by konfigurační volba jádra PROTECTED_STICKY_SYMLINKS měla být standardně zapnuta, ale celkově ho velmi zajímalo, že se patch konečně někam posouvá. Torvalds měl poněkud jiný pohled, Uff. Takhle implementace se mi fakt nelíbí., ale navrhl jiné mechanismy, které by se mohly pokusit vyřešit problém použitím bitů oprávnění na symbolickém odkazu. Jeho argumentem je to, že Cookův přístup není moc slušný, protože je ukrytý, čímž se z toho stává:

nějaké dohackované náhodné chování, které závisí na neviditelné konfigurační volbě, o které lidé ani neví.

Jak ale Cook poukazuje, Torvaldsův přístup má svou vlastní sortu podivného náhodného chování. Nelze popřít, že Torvalds svůj návrh úplně nepromyslel, ale je to známka zájmu o vyřešení problému. Z Cookova pohledu změny, které navrhuje, pouze mění chování sticky adresářů s ohledem na symbolické odkazy, přičemž Torvaldsův návrh by měl širší dopad na vytváření symbolických odkazů. Obojí by mohlo fungovat, ale Cookovo řešení má skutečně výhodu v tom, že navržené změny jsou už roky v provozu v grsecurity a Openwall a odnedávna také v Ubuntu.

Vzhledem k tomu, že několik významných jaderných hackerů je pro vyřešení problému – Ted Ts'o tomu byl v roce 2010 také pozitivně nakloněn – to vypadá, že na přístup přes kód VFS se usměje štěstí. Pokud Viro a ostatní vývojáři VFS nebudou úplně proti, mohli bychom to vidět ve verzi 3.4 (nebo tak nějak).

Pokud na to dojde, je tu ještě jeden související patch, který by se snad také dostal k začlenění do hlavní řady: omezení pevných odkazů (hardlinků). Toto, stejně jako změna symbolických odkazů, aktuálně žije v Yama, i když by se dalo obhajovat, že by to také šlo udělat ve VFS. Tento patch by zakázal vytváření pevných odkazů na soubory nepřístupné (nelze je číst, ani zapisovat) uživateli, který odkaz vytváří. Také to zakazuje pevné odkazy na soubory setuid a setgid. To by ucpalo další díry ve zranitelnosti kolem symbolických odkazů a vyřešilo by to i další zranitelnosti.

Pokud by se omezení symbolických i pevných odkazů dostala do VFS, v Yama by zůstalo jen omezení ptrace(). Tato omezení umožňují administrátorům zakázat procesu dělat ptrace() na cokoliv jiného než vlastní potomky (leda by proces měl zapnuto CAP_SYS_PTRACE). Aktuálně může jakýkoliv proces dělat ptrace na libovolném jiném procesu se stejným UID, takže kompromitování jednoho běžícího programu může vést k získání přístupových údajů a jiných citlivých informací z dalšího běžícího programu. Pak se mohou najít i další vylepšení DAC, které by Cook a jiní rádi viděli v Yama.

Tak či tak je problém natolik závažný, že by alespoň administrátoři a distributoři měli mít způsob, jak těmto běžným zranitelnostem zamezit. Ať už je oprava ve VFS nebo LSM, nabídnutí volby umožňující vypnout celou skupinu zranitelností – které mohou často vést ke kompromitování systému – vypadá, že stojí za to. Doufejme, že v tomto směru konečně začínají hýbat ledy.

Diskuse k tomuto článku

[peterix]

... A omezeni na ptrace si tam taky muze zustat. To IMHO nema v hlavni rade co delat, protoze je to skaredy hack a rozbiji to vsechny debuggery. Navic je to jak kanon na komara - bud je to zapnute a debuggery nejedou anebo vypnute, a muzou delat cokoliv. CAP_SYS_PTRACE je navic docela zlo, protoze uplne obchazi normalni kontrolu UID/GID. Tady je potreba trochu jine reseni, s jemnejsim nastavenim debugovacich prav. Mozna je i potreba zmodernizovat (nebo nahradit) ptrace.

[Sten]

ptrace je hodně moderní rozhraní, na to, že je jaderné (pro user space je určené třeba libgdb). A navíc omezování ptrace nemá s návrhem rozhraní moc společného, když ptrace je na omezování připraven (EPERM).

[adssa]

To je snad strojovej preklad !? Neda se to cist, panove.

[aaaaaaaaaaa]

Daj konkretne pasaze. Ja som Slovak (takze cestinu nepoznam az tak do hlbky), ale clanok mi nerobil problem a ani sa mi nezdal ako strojovy preklad.

[luky]

Obcas tam jsou ruzne nejasnosti, ktere vzniknou tim, ze autor prevezme slovosled a nebo strukturu vety.

Priklad: Pokud má program s chybou vyšší oprávnění

Spravne by melo byt: Pokud ma chybny program vyssi opravneni

Duvod je ten, ze pouzita formulace se da pochopit i tak, ze program ma vyssi opravneni kvuli chybe. Tady to jde snadno domyslet z kontextu, ale uz nekolikrat se mi stalo, ze jsem musel koukat do originalu, abych preklad pochopil.

Nekdy se vyskytne uplne divne spojeni typu "vánočka tvého výběru".

Nekdy se take stane, ze prekladatel nerozumi kontextu a proto to prelozi jinak: (namočená v likéru by taky nevadila.)

zde melo byt: (namočene v likéru by nevadily.) protoze do likeru (u nas spis tuzemaku a tomu bych liker nerikal ) se namaci susene ovoce pred tim, nez se da to testa. Rozhodne ne uz hotove vanocky.

U knizky by mi to asi vadilo, ale u clanku, ktery ctu jednou, takove chyby jako zavazny problem nevnimam.

[Luboš Doležel (Doli)]

Pokud ma chybny program vyssi opravneni

Je ale také nejednoznačné, protože se to dá pochopit, že vyšší oprávnění dostal jiný program, než měl

Nekdy se vyskytne uplne divne spojeni typu "vánočka tvého výběru".

Tady už jsem asi zdegeneroval, protože mi to přijde normální.

Nekdy se take stane, ze prekladatel nerozumi kontextu a proto to prelozi jinak: (namočená v likéru by taky nevadila.)

Tady jsem dost váhal, ale protože vánočky nejím (nechutnají mi), netušil jsem, která část se do likéru namáčí. Ale žena upozorňuje, že někde se vánočka namáčí při konzumaci do mléka s likérem

[luky]

Pokud ma chybny program vyssi opravneni

Je ale také nejednoznačné, protože se to dá pochopit, že vyšší oprávnění dostal jiný program, než měl

Problem je v tom, ze to "s chybou" se da povazovat za dva ruzne vetne cleny. Brali jsme to v devate tride (nekdy ke konci minuleho tisicileti ), tak doufam, ze nebudu ty terminy moc michat:

Zacnete tim, ze najdete podmet a prisudek:

program -- ma

a ted na to pomoci ruznych otazek postupne lepite zbytek. Na to "s chybou" se muzete ptat dvema zpusoby:

1. jaky program ma (...)? s chybou

zde se jedna o privlastek (neshodny), ktery se vaze na podmet a popisuje jeho vlastnosti

nebo

2. s cim ma program (...)? s chybou

zde se jedna o predmet, ktery se vaze na prisudek (sloveso ma) a je puvodce (vysledek atd.) deje.

V te formulaci, co jsem tam nastrelil ja, to "chybny" IMO nejde nalepit jinam.

[pavlix]

IMO to předmět být nemůže a „s čím“ mi vůbec nezní jako otázka na předmět.

[luky]

Na predmet se pta padovymi otazkami (krome 1. a 5.) a "s cim" je otazka k 7. padu. Jak rozlisit predmet a prislovecne urceni si uz nepamatuju.

[pavlix]

Jo, přesně tyhle problémy měla naše nejmenovaná učitelka na osmiletym gymplu. Měla s knížek načtené desítky pouček a ani kousek analytického myšlení a jazykového citu. Pak plodila v hodinách podobné nesmysly.

Když se podíváš třeba na českou wikipedii tak tam tu tvoji poučku najdeš a hned v další větě máš druhou poučku, která říká, že pokud se můžeš zeptat jinak než pádovou otázkou, tak to předmět nebývá.

Když se podíváš dál, tak tam máš napsáno, že předměty se řídí valenční vazbou slovesa, což je logické, protože předmět rozšiřuje přísudek. Z paty bych to možná vytáhl, ale tohle bylo rychlejší.

Sloveso mít se váže s kdečím, dokonce i s tím tvým sedmým pádem, ale ne samotným („mám s češtinou“), ale dohromady s čtvrtým pádem („mám problémy s češtinou“).

Což by teoreticky šlo napasovat na „program má vyšší oprávnění s chybou“, tzn. že zřejmě chyba i program mají (oba) vyšší oprávnění. Takže jsi přišel na další syntakticky správnou interpretaci té věty, gratuluju. Ale význam ta věta nemá, protože chybám se oprávnění nepřiděluje.

Každopádně jsem si díky tobě trochu zopáknul českou syntax, po letech :).

[pavlix]

Tak ani význam, že mají oba vyšší oprávnění bych ti neuznal. Vazba na 4. a 7. pád bude určitě fungovat, když „máš s někým dítě“, maximálně ještě když „máš (sdílíš) s někým byt“, ale jak tam dáš možné číslo, tak je z toho součást podmětu. Ale že by si program pořídil s chybou vyšší oprávnění :), to bys musel ten jazyk hodně znásilňovat.

[pavlix]

Tak ještě jednou, je to špatá analýza. Sloveso mít (mít/vlastnit něco, disponovat něčím) se váže výhradně na předmět ve 4. pádě, což je v téhle větě jednoznačně a pouze „vyšší oprávnění“.

Ale částečně máš pravdu, pokud to rozebereš důkladněji, opravdu dojdeš na to, že by „s chybou“ nemusel být přívlastek, ale mohlo by to příslovečné určení (zřejmě podmínky), protože je to odpověď na otázku kdy, za jaké podmínky, za jakých okolností.

Jenže jsem tyhle rozbory dlouho nedělal, a navíc teorie je mnohem exaktnější a jednoznačnější než praxe. Rozpoznávání větných členů se většinou dělalo tak, že jsi při zachování významu a tvaru zbytku věty nahradil větný člen vedlejší větou. Ale ani při zachování přívlastku ta věta není významově jednoznačná, a musíš vždycky význam lovit z kontextu.

„Pokudu má program s chybou vyšší oprávnění“

To by šlo interpretovat zhruba následujícími způsoby...

„(Pokud) má kterýkoli program, který obsahuje bezpečnostní chybu, navíc ještě vyšší oprávnění, …“

„(Pokud) má každý program, který obsahuje zmíněnou chybu, vyšší oprávnění, (…)“

„(Pokud) má libovolný program, jestliže obsahuje zmíněnou chybu, vyšší oprávnění, než jaké si měl ponechat, (…)“

Bez kontextu tady prostě nedáš ani ránu, a to zdaleka nejsou tyhle jen tři možnosti, protože každá z nich (snad kromě první) jde ještě sama o sobě interpretovat různě (kauzalita versus statistika, atd...). A navíc jsem ani tak určitě nevychytal všechny možnosti.

Mně osobně překlad vyhovuje a rozumím mu :). Ale tady přece dávno nejde o jaderné noviny, ale o hnidopišský jazykový kroužek™, takže přispívám svým hnidopišským jazykovým příspěvkem™ :D.

[luky]

Ono staci prehazet slovosled tak, aby melo "s chybou" vetsi vzdalenost od "ma" nez od "program", protoze v pripade vice moznosti se to vaze k tomu blizsimu.

[pavlix]

Ono staci prehazet slovosled tak, aby melo "s chybou" vetsi vzdalenost od "ma" nez od "program", protoze v pripade vice moznosti se to vaze k tomu blizsimu.

No není tak úplně pravda. Člověk při porozumění textu nebere při nejednoznačnosti v úvahu pouze vzdálenost slov ve větě, zvlášť v češtině ne.

Ale fakt je, že přívlastek by se měl nacházet u větného členu, který rozšiřuje, takže třeba odtržením a přesunutím na konec. Když to nebude přívlastek, tak ti v tomhle případě z hlediska syntaxe pouze příslovečné určení a předmět, ale v případě předmětu máš očividný významový nesmysl, v případě příslovečného určení máš divnou formulaci.

[Filip Jirsák]

„Chybný program“ a „program s chybou“ neznamená to samé – první označuje zásadní chybu zpravidla v tom, co je hlavní účel programu; ve druhém případě program splňuje svůj hlavní účel, ale v nějaké vedlejší funkci je chyba, které si třeba uživatel ani nemusí všimnout.

Pokud má program s chybou vyšší oprávnění

Duvod je ten, ze pouzita formulace se da pochopit i tak, ze program ma vyssi opravneni kvuli chybe.

V češtině ta věta tenhle význam mít nemůže. To byste musel vynechat tu předložku „s“.

[pavlix]

V češtině ta věta tenhle význam mít nemůže. To byste musel vynechat tu předložku „s“.

Člověk by čekal, že větu v hlavě pečlivě rozeberete než někoho začnete poučovat. Ta věta přesně takový význam mít může (stačí si na konec věty doplnit potenciálně vynechané „než bez ní“).

Tyhle hádky o češtině jsou otravné když se diskutující ani nezamyslí nad tím, jestli ten druhý nemůže mít pravdu.

[Filip Jirsák]

Já jsem psal o významu. Vytvořením věty „pokud má program s chybou vyšší oprávnění než bez ní“, která v kontextu článku žádný význam nemá, jste nic nedokázal. Je jasné, že případná chyba je vlastností programu, zatímco úroveň oprávnění určuje systém, takže ona chyba nemůže změnit úroveň oprávnění.

[kavol]

Je jasné, že případná chyba je vlastností programu, zatímco úroveň oprávnění určuje systém, takže ona chyba nemůže změnit úroveň oprávnění.

to je jasné možná tak z kontextu, navíc znalci, ale rozhodně ne náhodnému čtenáři jen z té diskutované věty

co třebas ... "pokud má Jeníček s Mařenkou více naloupaného perníčku" - z toho tedy jasně plyne, že případná Mařenka je vlastností Jeníčka, zatímco množství perníčku v košíčku určuje Ježibaba? - OMG ...

[Filip Jirsák]

Je to jasné všem, kteří tuší, že ten článek je o nějakém softwaru. Ostatně, kdyby ta věta mohla mít ještě nějaký druhý význam, už by ho tady někdo z té spousty diskutujících napsal a vyložil, že…

[pavlix]

Jenže ten, komu už je všechno jasné, přece nemusí žádné články číst :).

[luky]

která v kontextu článku

Ve svem komentari jsem psal, ze v tomto dile to jde z kontextu snadno domyslet, ale obcas se to objevi i na miste, kde to z kontextu nedomyslite. Prectete si par dilu zpet, urcite na to narazite (pokud se tedy budete snazit vse pochopit, nekdy je treba do jadra videt alespon na urovni Understanding the Linux kernel, aby si to clovek dokazal pospojovat).

Duvod je ten, ze pouzita formulace se da pochopit i tak, ze program ma vyssi opravneni kvuli chybe.

V češtině ta věta tenhle význam mít nemůže. To byste musel vynechat tu předložku „s“.

Tim "s" vyjadrujete vazbu mezi programem a chybou, bez ni by se mohlo jednat o chybu nekoho jineho, treba systemoveho administratora. Hodi se to napriklad na situaci, kdy nejaky server nezahodi po pripojeni uzivatele rootovska prava.

[kavol]

Tim "s" vyjadrujete vazbu mezi programem a chybou,

potud správně ...

bez ni by se mohlo jednat o chybu nekoho jineho, treba systemoveho administratora.

... ale tohle už neplatí

viz výše, "Jeníček s Mařenkou" mají také vazbu, ale to neznamená, že Mařenka je Jeníčkova - prostě se při loupání perníčku sešli a společně naloupali víc, než by zvládl Jeníček bez Mařenky ... stejně tak se mohla chyba třeba systémového administrátora projevit v onom programu - "pokud má program v součinnosti s chybou ..."

[pavlix]

prostě se při loupání perníčku sešli a společně naloupali víc

Sám ses nachytal.

[kavol]

prostě se při loupání perníčku sešli a společně naloupali víc

Sám ses nachytal.

co prosím? - měl jsem napsat naloupala, ta děcka?

[pavlix]

Tušil jsem, že se zeptáš...

Automaticky jsi použil množné číslo, což je dobře. Ale není to analogie k původní větě, kde je sloveso v singuláru, což funguje trochu jinak a vypadne ti jiná větná stavba.

[kavol]

tak ještě jednou a lépe:

viz výše, "Jeníček s Mařenkou" ...

[pavlix]

Tam už ta analogie funguje.

[kavol]

protoze do likeru (u nas spis tuzemaku a tomu bych liker nerikal ) se namaci susene ovoce pred tim, nez se da to testa. Rozhodne ne uz hotove vanocky.

co to meleš ty vořechu, samozřejmě že si do rumu namáčím hotovou vánočku!

[Ash]

Je rozdíl když to děláš ty, a když se to dělává (jako že to je zvykem) :D Každopádně ta věta měla být zhruba "hlavně aby byla čerstvá a nebyly v ní sušené kousky ovoce (namočené v likéru by nicméně nevadily.)" Ne že by na tom moc záleželo.

[kavol]

Je rozdíl když to děláš ty, a když se to dělává (jako že to je zvykem)

nuž, to už tady nedávno bylo ...

že něco neznáš/nechápeš ty také není normou

[luky]

Protoze znam lidi, co si do rumu namaceli i brambory, tak jsem ocekaval, ze se nekdo ozve. Nemyslim si ale, ze by s timto receptem nekdo uspel napriklad v televizni soutezi

[David Jaša]

Daj konkretne pasaze.

Konkrétně všechny, kde se vývojáři označují příjmením. Vzhledem ke zvykům (nejen) v jaderné komunitě to působí fakt divně.

[čha čha čha]

Ne. To je debilní překlad. Nicméně, většina Jaderných novin je tady debilně přeložena, takže se většina lidí už zvykla

[Dreit]

Tak překládej

[pet]

Zaplať pámbu za ty "debilní" překlady. Jsou milionkrát lepší než kdybych to měl louskat v originále. Mno, a co ti vlastně brání překládat sem lépe?

Každopádně všem co se na překladech jakkoli pozitivně podílejí co nejupřímněji děkuji a přeji vše nejlepší do nového roku.

[xxxs]

suhlas.

[pavlix]

Já bych to v angličtině přelouskal, ale málokdy se k tomu dostanu, kdyžto tady na Abclinuxu to mám hned na ráně.

Takže se přidávám.

Mně se ten překlad líbí, i když sem tam ujede nějaká chybka. Ani to s tou vánočkoumi nepřišlo divné a i když je to nejspíš chyba, nemá to vliv na obsah a vyznění článku.

[egg]

time-of-check-to-time-of-use; TOCTTOU

[vasek]

Jak se dá v programu vyhnout tomu TOCTTOU útoku? Vygooglil jsem nějaké pdfko, ze kterého mi tak nějak vyplynulo, že to možné ani není.

[Jakub Lucký]

V programech, kde to můžete vyřešit výjimkou by to jít mělo, viz. Python

try:
    f = open("/tmp/tocttou")
except OSError:
    #Něco v případě, že otevření souboru selže

[pavlix]

To by mě Jakube velice zajímalo, jak se to liší od céčkovského volání open, když je řeč o výjimkách. Mně připadá, že to s výjimkami nemá vůbec nic společného.

Jediné o co jde, je nespoléhat na stav souborů (například neexistenci) před jejich otevřením.

Podle letmého pohledu by mělo zafungovat toto:

O_EXCL

Ensure that this call creates the file: if this flag is specified in conjunction with O_CREAT, and pathname already exists, then open() will fail.

When these two flags are specified, symbolic links are not followed: if pathname is a symbolic link, then open() fails regardless of where the symbolic link points to.

V shellu by měl bohatě stačit mktemp.

[Ladicek]

V shellu by měl bohatě stačit mktemp.

V Céčku lze i mkstemp nebo tmpfile. Teda tak jsem to aspoň vykoumal, když jsem to nedávno řešil, ale do Céčka nedělám.

[pavlix]

Může být.

[Jakub Lucký]

Já tomu nerozumím, já jsem trapný highlevelista

Přiložím link: Python konference na archive.org

[Ladicek]

Tam nejde o tu výjimku, totéž by šlo udělat návratovým kódem. Tady

if os.path.isfile(some-file):
    os.unlink(some-file)

je mezi podmínkou isfile a voláním unlink prodleva, kde se může něco zvnějšku změnit. Zatímco v

try:
    os.unlink(some-file)
except OSError:
    pass

je ta operace kontrola + smazání atomická (což zajišťuje nějaké správné systémové volání).

[Jakub Lucký]

Jo, souhlasím, že nejde o výjimku obecně...

[guest]

dekuji vsem co za*rali diskuzi, takze tocttou mi zustane zahadou... jo, vim ze si to muzu najit.. jenze ten cas jsem vyplacal na cteni o z<|> cestine!