Jaderné noviny – 17. 10. 2013: Systémy souborů ve jmenných prostorech

4. 11. 2013 | Luboš Doležel | Jaderné noviny | 4139×

Aktuální verze jádra: 3.12-rc5. Citát týdne: Ingo Molnar. Odstraňování a přejmenování přípojných bodů.

Obsah

• Aktuální verze jádra: 3.12-rc5
• Citát týdne: Ingo Molnar
• Odstraňování a přejmenování přípojných bodů

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

Aktuální vývojová verze jádra je 3.12-rc5 vydaná 13. října. Linus poznamenal, že se vývoj uklidňuje a je celkem v dobré náladě.

Stabilní aktualizace: verze 3.11.5, 3.10.16, 3.4.66 a 3.0.100 vyšly 13. října. V řadě 3.0.x se dá očekávat asi už jen jedna aktualizace; ti, kdo používají 3.0, by měli uvažovat o přechodu.

Citát týdne: Ingo Molnar

Jednojádrové systémy se stávají historickou kuriozitou, proto bychom měli řádně odůvodnit každé složitosti, které kvůli nim přidáme.

-- Ingo Molnar

Odstraňování a přejmenování přípojných bodů

Připojení (mount) systému souborů je operace, která je obvykle vyhrazená pro uživatele root (nebo proces s právem CAP_SYS_ADMIN). Existují způsoby, jak obyčejnému uživateli umožnit připojit určité systémy souborů (např. výměnitelné disky jako CD nebo USB flashky), ale toto může být předem nutné nastavit administrátorem. Bind mounty, které připojují část už připojeného systému souborů na jiné místo, navíc vždy vyžadují oprávnění. Uživatelské jmenné prostory umožní jakémukoliv uživateli být rootem ve svém vlastním jmenném prostoru – tedy i připojovat soubory a systémy souborů (aktuálně) nečekanými způsoby. Asi se dá vytušit, že to může vést k nečekanému chování, které se patche od Erica W. Biedermana snaží řešit.

Problém se objeví, pokud se někdo pokusí smazat nebo přejmenovat soubor nebo adresář, který je jinde použitý jako přípojný bod [mount point]. Aby uživatel mohl soubor nebo adresář použít jako přípojný bod, stačí, aby k němu měl práva ke čtení (a práva ke spuštění u nadřazených adresářů), což znamená, že uživatelé mohou připojovat systémy souborů přes soubory, které nevlastní. Když se pak vlastník souboru rozhodne jej odstranit, dostane chybu EBUSY – bez zjevného důvodu. Bienderman navrhl změnu takovou, že by umožnil unlink nebo rename, ale došlo by k tichému odpojení čehokoliv, co tam bylo.

Pokud by například dva uživatelé vytvářeli nový přípojný bod a uživatelské jmenné prostory („user1“ vytváří „ns1“ a „user2“ vytváří „ns2“), existující jádra by vykazovala toto chování:

ns1$ ls foo
f1   f2
ns1$ mount foo /tmp/user2/bar

V druhém jmenném prostoru se user2 snaží odstranit svůj dočasný adresář:

ns2$ ls /tmp/user2/bar
ns2$ rmdir /tmp/user2/bar
rmdir: failed to remove ‘bar’: Device or resource busy

Viditelnost přípojných bodů v jiných jmenných prostorech přípojných bodů je součástí problému. Uživatel, který dostává EBUSY, nemusí mít vůbec možnost zjistit proč chybu dostává. Nemusí ani vidět připojený systém souborů pod svým souborem, jelikož byl vytvořen v jiném jmenném prostoru. Spolu s uživatelskými jmennými prostory by toto umožňovalo provádět DoS útok proti jiným uživatelům – včetně těch s vyššími oprávněními.

Biedermanovy patche nejprve přidávají sledování přípojných bodů do vrstvy VFS. To umožní pozdějším patchům dohledat jakákoliv připojení spojená s konkrétním přípojným bodem. Za použití tohoto je pak možné odpojit vše pod danou adresářovou položkou (dentry), což se přesně dělá při odstranění nebo přejmenování přípojného bodu.

Nápad byl obecně přijat dobře, jen Linus Torvalds měl námitku: některé programy jsou napsané tak, že očekávají, že rmdir() na neprázdném adresáři nemá žádné vedlejší účinky, protože jen vrátí ENOTEMPTY. Stávající implementace vrací EBUSY, pokud je adresář přípojným bodem, ale s Biedermanovy patchi by jakýkoliv systém souborů pod adresářem byl odpojen ještě dříve, než by bylo zjištěno, jestli adresáře je, nebo není prázdný a může být odstraněn. To vlastně do rmdir() přidává vedlejší účinek i v případě, že volání selže.

Navíc v závislosti na nastavení propagace přípojných bodů může připojený systém souborů být v jiném jmenném prostoru vidět. Takže uživatel dívající se na „svůj“ adresář může dokonce vidět soubory připojené jiným uživatelem. Pokud se ale pokusí smazat adresář, může se to podařit, protože příslušný adresář je ve skutečnosti prázdný.

Torvalds si nebyl vůbec jistý, jestli na tom nějaké aplikaci záleží, ale měl obavy, že takto dochází k většímu než nutnému zásahu do sémantiky. Měl také návrh, jak postupovat:

Pravdou ale je, že se mi líbí _nápad_ moci odstranit přípojný bod a související připojení během toho zkrátka zmizí. Ale v zájmu čistoty by tam mělo být něco jako „pokud je jeden z připojených systémů souborů v aktuálním jmenném prostoru, vrať -EBUSY“. Jinými slovy, patche by VFS umožnily odstranit přípojné body, ale obyčejný rmdir() by selhával, pokud by v tomto jmenném prostoru bylo něco připojené, aby bylo původní chování zachováno.

Biederman souhlasil a navrhl jiný patch, se kterým rmdir() selže s chybou EBUSY, pokud je na adresáři něco připojeného a je to z aktuálního jmenného prostoru. Pokud by to bylo z jiného jmenného prostoru, tak by nadále došlo k odpojení. Pak se ale vynořily otázky, zda by přejmenování (nebo unlink() na souborovém přípojném bodě) mělo být ošetřeno stejně.

Serge E. Hallyn se zeptal: Myslíte si, že bychom měli dělat to samé u přemountovaných souborů při vfs_unlink()? Jinými slovy, pokud je přípojný bod nad souborem, který je odstraňován (unlink()), a ne nad adresářem, mělo by platit stejné pravidlo? Otázka pak byla rozšířena tak, aby se týkala i rename(). Biederman si zpočátku myslel, že tato pravidla by se měla dotýkat jen rmdir(), jelikož věřil, že práva na nadřazených adresářích by měla stačit na to, aby při těchto dalších operacích docházelo k problémům. Ale po rozprávce s Miklosem Szeredim a Andym Lutomirskim změnil názor. Pro zachování konzistence a odstranění race condition ze starších verzí příkazu fusermount (před UMOUNT_NOFOLLOW) je nejpraktičtějším řešením blokovat unlink, rename a rmdir, pokud se tam v aktuálním jmenném prostoru nachází přípojný bod.

Race condition s fusermount se tu objevuje proto, že se snaží ujistit, že přípojný bod, který odpojuje, se za běhu nezmění. Zákěřný uživatel by mohl nahradit přípojný bod symbolickým odkazem na jiný systém souborů, který by fusermount běžící s právy roota ochotně odpojil. Dříve Biederman považoval tento problém za nepřekonatelnou překážku při opravování problému s rmdir(). Ale zakázání přejmenování přípojných bodů většinu obav z race conditions v fusermount ruší. Stále tu jsou nepravděpodobné scénáře, kdy by starší binárka fusermount s novějším jádrem mohla být podvedena tak, aby došlo k odpojení libovolného systému souborů, ale Szeredi, který je správcem FUSE, nemá obavy. Stojí za poznámku, že i ve stávajících jádrech jsou další způsoby, jak „zvítězit“ nad race condition (například přejmenováním nadřazeného adresáře přípojného bodu).

Nové patche odrážející návrhy těch, kteří kód revidovali, byly zveřejněny 15. října. Biederman cílí na jádro 3.13, takže ještě zbývá čas, kdy se lidé mohou ozvat s připomínkami. Ti, kteří se v této oblasti pohybují, by tomuto určitě měli věnovat pozornost, protože dochází k drobným dlouhodobým změnám v tom, jak se jádro chová.

Jde svým způsobem o další příklad neúmyslných důsledků uživatelských jmenných prostorů. Pokud uživatelské jmenné prostory nejsou povoleny, pak je celý problém jen zdrojem zmatků; k DoSu může dojít, jen pokud jsou povoleny. Pokud ale distribuce někdy uživatelské jmenné prostory povolí, pak tyto problémy budou muset být odhaleny a opraveny.

       

Komentáře

[Vantomas]

Jmenné prostory... Že by nějaká předzvěst kontejnerů na úrovni jádra přímo v systému? Nebo jaké využití existují pro takovou věc?

[luky]

Kde jste byl poslednich 5 let? http://en.wikipedia.org/wiki/LXC

[asdfasfasfasf]

cituji: A namespace is just how you label and organize information. In whatever OS you are used to, the primary namespace you work within is the filesystem saved on your hard drive. Another common namespace is the www* namespace of websites. Both of these systems illustrate how important namespaces are. A badly organized hard drive means you cant find your own files. The designers of Plan 9 decided to put a powerful new namespace paradigm at the heart of the system. There are several important principles you must know.

Your namespace is not simply a map of the local filesystem You are free to alter your namespace, and altering your namespace does not alter the resources your namespace is based on You may work within multiple different namespaces at once Each process you control has its own view of namespace which might be different from yours

Learning to work with multiple independent namespaces is like the difference between riding in a train on a set of preset tracks, and flying in an airplane in three dimensions. You can't get lost if you follow the tracks, but you also don't have freedom of where to go.

nejlepe ma NS (namespace) zvladnute plan9 from bell labs.

http://plan9.bell-labs.com/sys/doc/names.html

http://homepage.cs.uri.edu/~thenry/resources/unix_art/plan9.html

http://www.quanstro.net/plan9/srvtalk/srv.html

[Sten]

Na kontejnery se to již používá, ale tam nejspíš nebude docházet k zde řešeným problémům s mountpointy. Tohle je určené spíš pro per-user sandboxing na sdíleném systému, dovedl bych si představit něco ve stylu Androidu (každá aplikace má své UID a může být dost detailně nastaveno a jádrem vynuceno, co smí a co ne).