Vlákno názorů k článku
Oprava dlouholetého bezpečnostního problému v jádře 2.6.27 od BLEK. - Hmm, jen nevím, kdo bude všechny knihovny a...

Hmm, jen nevím, kdo bude všechny knihovny a pluginy, co Mozilla používá, měnit, aby ten nový flag použily.

Možná by bylo bývalo lepší udělat per-thread flag, který říká, že všechny file-descriptory vytvořené threadem mají nastaven close-on-exec. Pak by ho Mozilla mohla nastavit a knihovny a pluginy by vytvářely soubory s close-on-exec automaticky aniž by o tom věděly.

A co kdyz na te vlastnosti nektery plugin bude zaviset? Tak mu zariznete file descriptory jen tak? Vcetne prvnich tri?

Plugin, vzhledem k tomu, že běží v procesu Mozilly a musí se snášet s ostatními pluginy, nesmí modifikovat první tři file-deskriptory. Pak by celá Mozilla nemohla nic psát na terminál. Navíc pak hrozí, že se různé pluginy o ty deskriptory 0, 1 a 2 poperou.

Co se týče možnosti, že plugin vytvoří filedeskriptor s náhodným číslem, pak udělá fork(), exec() a execnutému procesu chce tento nový file deskriptor předat --- ano, to by tato změna zablokovala, otázka je, proč by plugin nějakému procesu takhle chtěl předávat file deskriptory s náhodným číslem a který program vlastně je schopen akceptovat jiné deskriptory než 0, 1, 2.

Proc by to mel byt nejaky nahodny filedescriptor? Neni problem si ho pripadne nejak predat.

Celkove, mnohem rozumnejsi mi prijde, ze si aplikace sama pred execem uklidi senzitivni kanaly na zaklade vlastnich znalosti a ne, ze se nejakym zpusobem globalne vnuti takove chovani.

Zrovna tak by mohl "forknutý" proces na začátku zavřít všechny nepotřebný deskriptory, ještě než zavolá exec() nějakého nebezpečného procesu. Je to jednodušší, než rešit ten race-condition, co popisuje UD, a je to IMHO i jednodušší, než přepsat všechny open() & spol. v celý Mozille.

Jo, takhle to dost programů taky dělá.