Portál AbcLinuxu, 19. dubna 2024 02:50
Aktuální verze jádra: 2.6.35-rc1. Citáty týdne: Alan Cox, Thomas Gleixner, Rafael Wysocki, Andrew Morton, Al Viro. Nečinnost ACPI nečinnosti. Senzory okolního osvětlení. Začleňovací okno 2.6.35, část třetí. Co přijde po blokování uspání? Symbolické odkazy ve „sticky“ adresářích.
Současné vývojové jádro je 2.6.35-rc1 vydané 30. května. Mezi změny od minulého týdne patří „ramoops“ (ukládání informací o oops do trvalé paměti), podpora přímého I/O v Btrfs a nějaké změny toho, jak je řešeno truncate(). Shrnutí změn najdete v článku níže, všechny detaily v kompletním changelogu.
Stabilní aktualizace: 1. června bylo vydáno 2.6.32.15. Odstraňuje dva patche, které uživatelům 2.6.32.14 způsobovaly problémy; o aktualizaci by měli přemýšlet jenom ti, kteří mají problémy.
-- Alan Cox
-- Andrew Morton a poslední kapka do poháru patchů
-- Al Viro
napsal Jonathan Corbet, 1. června 2010
Len Brown strávil několik let na tom, aby měl Linux co nejkvalitnější podporu ACPI. Je tedy zajímavé vidět ho, jak pracuje na vyzkratování částí kódu ACPI; to se stalo u nového ovladače cpuidle pro nové procesory Intelu. S touto experimentální vlastností – začleněnou do 2.6.35 – přepínání stavů nečinnosti u procesorů Nehalem a Atom v Linuxu již nezávisí na ACPI.
ACPI BIOS je ve světě x86 standardním způsobem přepínání procesorů do nečinnosti. Proč by ho tedy Linux měl chtít v ovladači cpuidle opustit? Len vysvětluje:
Motivujícím faktorem se zde zdá být bug v BIOSu, který se v systémech od Dellu dodával po několik měsíců a který zakazuje několik stavů nečinnosti. Výsledkem je, že Lenův testovací systém spotřebovává 100 W při používání kódu ACPI; když jsou stavy nečinnosti řízeny přímo, spotřeba energie klesá na 85 W. Fakt, že Linux tak spotřebovává významně méně energie než jiné operační systémy – které stále závisí na ACPI – je jenom třešničkou na dortu.
Obecně dává smysl používat vlastnosti hardwaru přímo a preferovat je před řešeními pomocí BIOSu, pokud máme dostatek informací, abychom to mohli udělat. V takových situacích může mít mnoho výhod vynechat prostředníka ve firmwaru. Je hezké vidět, když výrobce čipů – který jednoznačně potřebné znalosti má – svůj hardware podporuje tímto způsobem.
napsal Jonathan Corbet, 2. června 2010
Senzory okolního osvětlení dělají přesně to, co říká jejich jméno: Sdělují systému, jak osvětlené je prostředí okolo něj. Jsou užitečné pro záležitosti jako automatické nastavení jasu obrazovky pro nejlepší čitelnost. V jádře jsou nyní ovladače pro několik takových senzorů, ale neexistuje žádný standard pro rozhraní do uživatelského prostoru. Andrew Morton si nedávno tohoto problému všiml a navrhl, že by ho bylo vhodné ho opravit. Tohle je velmi důležité! Zdá se, že děláme velký nepořádek, který nebudeme nikdy moci uklidit.
Jak se stává, vývojáři ovladačů pro tyto senzory se dané problémy pokusili vyřešit již dříve v tomto roce. Jejich práce kulminovala požadavkem na přetažení, kde žádali Linuse, aby přijal framework pro světelné senzory do 2.6.34. K přetažení ale nedošlo; Linus si myslel, že tyto senzory by měly být prostě považovány za jiný druh vstupního zařízení (pro interakci s člověkem); jiní žádali, aby byl framework rozšířen o podporu dalších typů senzorů. Od té doby zmizel.
Framework pro světelné senzory možná nebyl připraven, ale konečným výsledkem je to, že vývojáři byli odrazeni a každý ovladač, který míří do systému, má nyní různé, nekompatibilní API. Další ovladače čekají na to, až se věci stabilizují; Alan Cox to komentoval: V Intelu máme nějaké ovladače, které zašleme, až zvítězí soudnost. Problém zjevně vyžaduje nějaké řešení, ale není jasné, kdo se o něj pokusí a co se potom stane.
napsal Jonathan Corbet, 31. května 2010
Začleňovací okno bylo zakončeno vydáním 2.6.35-rc1 30. května. Od shrnutí z minulého týdne bylo začleněno relativně malé množství změn; nejvýznamnější jsou shrnuty zde.
Mezi změny viditelné pro uživatele patří:
Ovladač „ramooops“ umožňuje systému zaznamenat informace z oopsu v trvalé RAM, odkud je lze později obnovit.
Souborový systém Btrfs získal základní podporu pro přímé I/O.
FUSE nyní umožňuje implementacím souborového systému v uživatelském prostoru přenášet dat pomocí systémového volání splice(), čímž odpadá operace kopírování.
Byla přidána nová, experimentální podpora pro stavy nečinnosti CPU, která nepoužívá ACPI. Zdá se, že při troše snahy je možné ušetřit více energie přímým řízením stavů nečinnosti, než když se o ně stará ACPI BIOS.
Mezi změny viditelné pro vývojáře jádra patří:
API funkcí pro uživatelský režim [user-mode helper API] (jádro ho používá pro spouštění programů v uživatelském prostoru) se trochu změnilo. call_usermodhelper_setcleanup() nyní vypadá takto:
void call_usermodehelper_setfns(struct subprocess_info *info,
int (*init)(struct subprocess_info *info),
void (*cleanup)(struct subprocess_info *info),
void *data);
Nová funkce init() bude zavolána z pomocného procesu těsně před vykonáním pomocné funkce. Také je zde nová funkce:
call_usermodehelper_fns(char *path, char **argv, char **envp,
enum umh_wait wait,
int (*init)(struct subprocess_info *info),
void (*cleanup)(struct subprocess_info *), void *data)
Tato varianta je jako call_usermodhelper(), ale umožňuje specifikovat inicializační a úklidovou funkci naráz.
Členská proměnná fsync() struktury struct file_operations ztratila argument – ukazatel na struct dentry, který nikdo nepoužíval.
Byly začleněny patche nového způsobu zkracování souborů, které mění způsob, jakým je ve vrstvě VFS řešeno truncate().
Jako vždy nějaké věci začleněny nebyly. Blokování uspání se do jádra nedostalo; není ani divu vzhledem k diskuzi, jaká se vedla na konci začleňovacího okna. Rozhraní pro upozorňování na události souborů fanotify také ne, přestože se neobjevila žádná veřejná opozice. Také nebylo začleněno nejnovější zaslání usond [uprobes]. Mimo hlavní řadu zůstávají souběžností řízené fronty, stejně jako sada patchů, která pro tuto vlastnost připravuje půdu. Transparentní velké stránky se nedostaly, ale pro tento kód bylo tak jako tak ještě příliš brzy. Systémové volání pro otevírání souborů pomocí manipulátoru prošlo před a během začleňovacího okna několika revizemi, ale zůstalo nezačleněno. Mnoho z těchto vlastností to pravděpodobně v 2.6.36 zkusí znovu, jiné pravděpodobně zmizí.
Suma sumárum bylo během začleňovacího okna 2.6.35 přijato nějakých 8 113 neslučovacích sad změn – výrazně více než 6 032 začleněných během začleňovacího okna 2.6.34. Linusovo oznámení naznačuje, že by si po vydání -rc1 mohly svou cestu do jádra najít ještě nějaké změny, ale jejich počet bude malý. Na tomto vývojovém cyklu zatím spolupracovalo téměř přesně 1000 vývojářů. Jak Linus poznamenal v oznámení 2.6.35-rc1, vývojový proces dál vypadá zdravě.
napsal Jonathan Corbet, 31. května 2010
Vypadalo to skoro jako hotová věc: Po více než roce diskuzí se zdá, že většina námitek proti „blokování uspání“ v Androidu je vyřešena. Kód se přesunul do stromu, odkud je kopírován do linux-next a Linusovi byl zaslán požadavek na přetažení. A zbývá jenom počkat, jestli ho Linus přetáhne, což se ale nestalo; ke konci začleňovacího okna diskuze znovu obživla a tento výsledek tedy nebylo překvapení. Diskuze, jež nakonec pohřbila všechny naděje, které měl tento kód na začlenění, nicméně poskytla počáteční návrhy přístupu, který by mohl být přijatelný pro všechny zúčastněné. Tento článek se podívá na technické záležitosti okolo posledního kola námitek a potenciální řešení.
Jenom pro připomenutí: Blokování uspání (dříve „probouzecí zámky“) je součástí systému správy napájení na telefonech s Androidem. Kdykoliv je to možné, chtějí vývojáři Androidu telefon přepnout do stavu kompletního uspání, kdy je minimalizována spotřeba energie. Android se automaticky („oportunisticky“) uspává, i když jsou v systému běžící procesy – tímto způsobem lze špatně napsaným programům zabránit v tom, aby příliš rychle vybily baterii.
Jenže telefon, který je neustále uspaný, i když vydrží na jedno nabití opravdu dlouho, také není příliš užitečný. Jsou tedy okamžiky, kdy je nutné, aby telefon běžel; mezi tyto okamžiky patří jakékoliv období, kdy je zapnutý display. Také je důležité telefon neuspat, když se dějí zajímavé věci; a zde přichází blokování uspání. Například událost stisku klávesy zablokuje uspání v jádře; tento blok je uvolněn poté, co danou událost přečte uživatelský prostor. Aplikace v uživatelském prostoru před čtením události zablokuje uspání sama o sobě; tím je zajištěno, že systém poběží dál i poté, co jádro uvolní první blok. Blok v uživatelském prostoru je uvolněn poté, co je událost zcela zpracována; v takové situaci se telefon může uspat.
Nejnovější kolo námitek obsahovalo nějaká témata, která bylo možné slyšet již dříve: Konkrétně se jednalo o ABI blokování uspání, které – když bude přidáno do jádra – bude nutné velmi dlouho udržovat. Vzhledem k tomu, že s tímto ABI bylo mnoho lidí nespokojeno, není překvapivé, že mnoho vývojářů jádra jím nechce být zatíženo navždy. Také jsou zde obavy, že by blokování uspání v jádře „nakazilo“ rostoucí počet ovladačů. A nápad, že by jádro mělo fungovat jako ochrana systému proti špatně napsaným aplikacím je nadále kontroverzní; někdo ji jednoduše považuje za způsob, jak získat robustnější systém, zatímco jiní v tom vidí recept na šíření špatného kódu.
Další kritika ale pochází z jiného směru: Blokování uspání je podle některých řešení správy zdrojů hrubou silou; problém přitom lze řešit (a měl by tak být řešen) způsobem, který je flexibilnější, splňuje potřeby širšího okruhu uživatelů a není vázán na současný hardware Androidu. V tomto pohledu není „uspání“ žádný zvláštní a unikátní stav systému; je to pouze obzvlášť hluboký stav nečinnosti, který lze řídit obvyklou logikou cpuidle. Jádro aktuálně používá informace o kvalitě služby [quality-of-service, QOS], které lze poskytnout pomocí API pm_qos a podle kterých si vybírá stavy nečinnosti; s rozšířením pohledu na QOS lze do stejné logiky zahrnout i kompletní uspání.
Jinými slovy, současná jádra pomocí cpuidle již implementují nápad „oportunistického uspávání“ – pro sadu stavů spánku, kterou zná současný kód. Na hardwaru x86 je opravdové „uspání“ [suspend] jiný stav, než které zná cpuidle, ale (1) jádro by tyto rozdíly mohlo skrýt a (2) architektury, které jsou více orientovány na embedded aplikace, již nyní většinou považují uspání za jeden ze stavů nečinnosti. Existují náznaky, že se x86 bude posouvat stejným směrem, kde na uspání nebude nic zvláštního.
Jsou zde však jisté rozdíly na úrovni softwaru. Do současných stavů nečinnosti se přechází jenom v případě, že je systém opravdu nečinný, zatímco k oportunistickému uspání může dojít, i když nějaké procesy běží. Nečinné stavy nezastavují časovače v jádře, uspání ano. Uspání je jinými slovy pohodlný způsob, jak všechno zastavit – bez ohledu na to, jestli by se to zastavilo samo – dokud se neobjeví nějaká dostatečně zajímavá událost. Tyto rozdíly vypadají – aktuálně – jako dostatečné zdůvodnění, proč „čisté“ řešení pomocí QOS není možné; věci ale mohou zamířit daným směrem, takže má cenu se danou vizí zabývat.
Zopakujme: Současné stavy nečinnosti CPU jsou jádrem vybrány na základě požadavků na kvalitu služby, kterou si vybírá jádro. Jestliže nějaký subsystém prohlásí, že potřebuje být spouštěn s latencemi v řádu mikrosekund, jádro ví, že nemůže použít stav hlubokého spánku. Když do tohoto modelu přidáme uspávání, pravděpodobně přibude nová úroveň kvality služby, která je často nazývána „QOS_NONE“ a která specifikuje, že je přípustná jakákoliv latence. Jestliže v systému nic nežádá kvalitu služby lepší než QOS_NONE, jádro ví, že může jako stav nečinnosti použít „uspání“, pokud to dává smysl. Samozřejmě se jádro také bude muset ujistit, že lze všechny naplánované časovače pozdržet do nekonečna; tuto informaci může poskytnout mechanismus časovačů s volností, který již existuje, ale který je nový a téměř se nepoužívá.
Na takovém systému mohou nedůvěryhodné aplikace běžet v nějakém vězení [jail] (nebo řekněme v řídící skupině), kde budou omezeny na QOS_NONE. V některých verzích může být úroveň kvality služby pro tuto skupinu dynamicky měněna mezi „normální“ a QOS_NONE v závislosti na tom, co si systém jako celek myslí, že by bylo dobré uspat. Jakmile budou nedůvěryhodné aplikace takto označeny, nemohou systému zabránit v uspání – téměř.
Jeden malý problém spočívá v tom, že pokud bude uspání stav nečinnosti, musí být systém nečinný předtím, než bude možné uspat. Pokud bude aplikace prostě sedět na CPU, může systému jako celku stále bránit v uspání. Oportunistické uspávání u Androidu je navrženo tak, aby tento problém vyřešilo; systém se uspí bez ohledu na to, co se aplikace pokouší udělat. Když bude toto vynucené uspání chybět, musí být jiný způsob, jak aplikacím zabránit v tom, aby držely systém vzhůru.
Objevil se zajímavý nápad, že by stav QOS_NONE znamenal, že proces může neomezeně dlouho čekat na CPU, i když je ve stavu spustitelný [runnable]; plánovač by poté rozhodl, že systém bude nečinný, pokud mohou běžet jenom procesy QOS_NONE. Peter Zijlstra má ale obavy, že když bude takovým úlohám bráněno v běhu, nevyhnutelně to povede ke všem možným problémům s prioritou a inverzí zamykání; do toho by se pouštěl nerad. Tento přístup se tedy daleko nedostal.
Alternativou je odložit všechny I/O operace, které požadují procesy s QOS_NONE, když se systém pokouší uspat. Proces, který čeká na I/O, je přirozeně nečinný; pokud můžeme předpokládat, že i aplikace nejnáročnější na procesor dříve či později budou chtít provést nějaké I/O, mělo by být možné takto zablokovat všechny procesy. Další možnost je vytvořit démona pro uživatelský prostor, který bude procesy informovat o tom, že je čas přestat pracovat. Každému procesu, který nevyhoví, to lze připomínat čím dál tím urgentnějšími signály včetně SIGKILL, když to dojde tak daleko.
Přístupy, jako je tento, lze implementovat a mohlo by to snadno být dlouhodobé řešení. Nejsou ale okamžité řešení. Mezi jinými věcmi bude řešení založené čistě na QOS vyžadovat, aby ovladače měnily úroveň kvality služby v reakci na události. Když se stane něco zajímavého, systému by nemělo být dovoleno se uspat, dokud uživatelský prostor nedostane možnost zareagovat. Důležité ovladače tedy bude nutné rozšířit o interní volání QOS – což v podstatě znamená blokování uspání v jádře ve všech ohledech kromě jména. Bude nutné změnit časovače, aby ty, které lze odložit na neurčito, neblokovaly uspání. Také možná bude nutné dočasně zvýšit úroveň kvality služby aplikacím, které budou události zpracovávat. To vše lze pravděpodobně udělat způsobem, který půjde začlenit, ale problém Androidu to hned nevyřeší.
V relativně blízké budoucnosti tedy možná uvidíme řešení založené na přístupu, který popsal Alan Stern. Alanův nápad zachovává využívání vynuceného uspání, ale ne v oportunistickém režimu. Místo toho by byl režim „QOS uspání“, kterého by se dalo dosáhnout explicitním zápisem „qos“ do /sys/power/state. Pokud nebudou žádná omezení na kvalitu služby, když je vyžadováno uspání, systém se uspí okamžitě; v opačném případě proces, který zapsal do /sys/power/state, bude blokovat, dokud daná omezení nezmizí. Krom toho by se zavedlo nové omezení na kvalitu služby QOS_EVENTUALLY, které by bylo kompatibilní s jakýmkoliv stavem nečinnosti kromě uspání. Toto omezení – které by bylo možné držet pouze v jádře – by zablokovalo uspání v době, kdy se něco děje.
Jinými slovy by se jaderné blokování uspání v Androidu změnilo na omezení QOS_EVENTUALLY. Rozdíl je v tom, že když se hraje podle omezení QOS, jádro může nejlépe rozhodovat o tom, jak tato omezení splnit.
V Alanově přístupu není žádné blokování uspání v uživatelském prostoru; místo toho je zde proces – démon – který se pokouší systém přepnout do stavu „uspání QOS“ pokaždé, když si myslí, že se neděje nic zajímavého. Aplikace mohou tomuto démonu sdělit požadavek, aby se systém uspal; démon může (ale nemusí) těmto požadavkům vyhovět podle toho, jakou politiku implementuje. Systém se tedy uspí v okamžiku, kdy se jádro i uživatelský prostor shodnou, že je to správně a že to nebude vyžadovat, aby byly všechny procesy nejprve nečinné. Tento mechanismus také zjednodušuje sledování toho, které procesy uspání blokují – což je pro lidi od Androidu důležité.
Ve shrnutí, jak ho napsal Alan:
Vývojář Androidu Brian Swetland souhlasil a řekl: … z toho, co vidím, se zdá, že nám tento model poskytuje funkcionalitu, kterou hledáme.. Možná tedy máme podobu skutečného řešení.
Samozřejmě zbývá hodně věcí, které je potřeba dotáhnout do konce. Krom toho jsou stále diskutovány alternativy; například jeden přístup by nahradil probouzecí zámky v uživatelském prostoru speciálním zařízením, které by šlo použít k vyjádření omezení pro kvalitu služby. Je tu také nepříjemná záležitost související s tím, že nikdo nezaslal žádný kód. Nicméně když od tohoto problému odhlédneme, zdá se, že největší překážka, která tak velkému množství kódu Androidu stála v cestě do jádra, bude konečně rozbita.
napsal Jake Edge, 2. června 2010
Bezpečnostních problémů, které zneužívají špatně napsané programy tím, že vloží symbolický odkaz do /tmp, je celá řada. Tyto nedostatky v aplikacích existují již od úsvitu UNIXových časů a pravidelně se objevují nové. Nedávná snaha změnit jádro tak, aby se těmto problémům zabránilo, by se tedy na první pohled zdála být vítaná. Někteří jaderní hackeři nicméně nejsou přesvědčeni o tom, že by jádro mělo opravovat špatně napsané aplikace.
Tyto souběhy v /tmp jsou třída bezpečnostních problémů, které jsou známy jako chyby období mezi kontrolou a použitím [time-of-check-to-time-of-use, TOCTTOU]. Chybně napsaná aplikace u souborů v /tmp typicky zkontroluje, jestli daný soubor existuje a/nebo jestli má správné vlastnosti; jestliže soubor testům vyhoví, program ho použije. Útočník to zneužije tak, že do /tmp mezi kontrolou a otevřením/vytvořením vloží symbolický odkaz nebo jiný soubor. To útočníkovi umožní obejít všechny kontroly, které mají být vynuceny.
U programů s běžnými oprávněními mohou tyto útoky vést k různým problémům, ale nevedou k napadení systému. U setuid programů může ale útočník využít zvýšená privilegia a přepsat libovolné soubory tak, že to může vést ke všem možným ošklivostem, včetně kompletního ovládnutí systému eskalací privilegií. Jsou různé příručky, které popisují to, jak se takové slabině při psaní kódu vyhnout, ale nové slabiny jsou i tak hlášeny poměrně často.
Člen bezpečnostního týmu Ubuntu Kees Cook navrhl změnu jádra tak, aby se danému problému zabránilo ne odstraněním souběhu, ale tak, že se programům zabrání následovat [follow] symbolický odkaz, který byl vytvořen. „Správná“ oprava v aplikaci se souběhu zcela vyhne tím, že použije náhodné jméno souboru a soubor vytvoří s O_CREAT|O_EXCL. Jenže vzhledem k tomu, že problémy již po několika desetiletích varování raší dál, možná je načase použít jiný přístup. Kees upravil kód z jader Openwall a grsecurity a jiný přístup byl na světě.
Vzhledem k tomu, že k problémům dochází ve sdílených adresářích (jako /tmp a /var/tmp), do kterých může zapisovat kdokoliv, ale které mají zapnutý „sticky“ bit, takže každý uživatel má možnost mazat pouze svoje soubory, omezuje patch to, které symbolické odkazy ve sticky adresářích lze následovat. Aby bylo možné následovat symbolický odkaz v sticky adresáři, musí ho buď vlastnit ten, kdo následuje, nebo musí adresář a odkaz mít stejného vlastníka. Vzhledem k tomu, že sdílené adresáře typicky vlastní root a náhodní útočníci nemohou vytvářet symbolické odkazy vlastněné rootem, je problém souběhů způsobený symbolickými odkazy v /tmp odstraněn.
Po první verzi patche se objevilo několik doporučení a ACK od Serge Hallyna, ale žádné stížnosti. Kees si zjevně problém nastudoval a předvídal nějaké námitky z dřívějších diskuzí na linux-kernel, které k zaslání připojil. Také dal odkaz na seznam 243 CVE záznamů, které zmiňují /tmp – ne všechny se týkají souběhů se symbolickými odkazy v /tmp, ale mnohé ano. Když Kees patch revidoval a zaslal znovu, objevilo se několik stížností.
Kees očekával, že vývojáři VFS budou mít námitky proti vložení testu do jejich kódu, takže ho vložil do kontroly kvalifikací [capabilities] (cap_inode_follow_link()). To příliš nesedlo Ericovi Biedermanovi, který řekl:
Alan Cox souhlasil, že by to mělo přijít buď do SELinuxu, nebo do nějakého specializovaného linuxového bezpečnostního modulu (LSM). Také navrhl, že dát každému uživateli jeho vlastní přípojný bod pro /tmp by problémy vyřešilo také bez nutnosti jakkoliv měnit jádro. Dej každému uživateli jeho vlastní /tmp. Žádné změny jádra, žádné špatné chování, žádné podivné čachrování s následováním cest. Nevidím nic, co by vyžadovalo patch jádra.
Kees a ostatní ale nejsou přesvědčeni, že legitimní aplikace potřebují následovat takové symbolické odkazy. Vzhledem k tomu, že jejich následování bylo zdrojem mnoha závažných bezpečnostních problémů, proč to jednou provždy neopravit v jádře? Dalo by se argumentovat tím, že toto chování by porušilo standard POSIX – což je jedna z námitek, kterou Kees očekával – ale tento argument nemusí mít nutně velkou sílu. Ted Ts'o věří, že POSIX zde neplatí, protože nedefinuje sticky bit:
/tmp adresáře specifické pro uživatele by mohly problém vyřešit, ale staly by se samy o sobě zátěží pro administrátory. Eric Paris podotýká, že by to jako řešení mohlo být lepší, ale nebude to zadarmo:
Ted souhlasí: Spíš jsem proti samostatným /tmp pro jednotlivé uživatele, protože budou matoucí pro správce a protože by je mohly zneužít rootkity a skrýt se takovými způsoby, které by pro většinou správců bylo těžké odhalit. Na základě toho a dalších komentářů Kees patche revidoval ještě jednou a přesunul test do VFS místo toho, aby se pokoušel používat bezpečnostní subsystém.
Krom toho kód změnil tak, aby toto chování bylo ve výchozím nastavení vypnuté, což reagovalo na jednu z největších námitek. Verze 3 patche byla zaslána 1. června, zatím ji komentoval jen Al Viro, který podle všeho není přesvědčen, že je taková změna zapotřebí, ale který se i tak zabýval detaily implementace.
Může se stát, že Al i další vývojáři souborových systémů – Christoph Hellwig například podle všeho není této změně příliš nakloněn – budou proti. Do určité míry je to náplast chránící špatně napsané aplikace, ale také poskytuje určité prostředky pro ochranu, které by někteří měli rádi k dispozici. Jak podotkl Kees, jádro Ubuntu již tuto ochranu má, ale on by byl rád, aby se rozšířila na všechny uživatele v jádře. Jestli se tak stane, se ještě uvidí.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.