FUSE: SSHFS a EncFS

12. 9. 2012 | Luboš Doležel | Systém | 13060×

V tomto seriálu se podíváme na různé souborové systémy, které jsou k dispozici pod Linuxem díky FUSE (Filesystem in Userspace). V prvním díle najdete popis FUSE a ukázku SSHFS a EncFS.

Obsah

• Co je to FUSE
• SSHFS
• EncFS
• Závěr

Co je to FUSE

Nejprve si vysvětlíme, co to FUSE vlastně je. Implementace souborových systémů (jako ext4 nebo NFS) se obvykle nacházejí v jádře. Právě tam je možné zajistit co nejvyšší dostupnost a výkon, který je pro takto kritickou komponentu nutný. Vývoj modulu souborového systému tedy znamená vývoj pro jádro, což je ale v různých ohledech náročnější než vývoj běžných programů. Pro uživatele pak instalace externího modulu souborového systému může často znamenat nutnost kompilace – což vzhledem k častým změnám v jaderném API nemusí vždy skončit úspěchem – dále nutnost práv uživatele root k zavedení jaderného modulu a připojení a nesmíme zapomenout na riziko pádu jádra, pokud se v modulu vyskytnou chyby.

FUSE je v tomto ohledu revoluční. Tedy ne úplně. To, že uživatelé mohou vyvíjet vlastní souborové systémy a ty pak na systému provozovat bez ohrožení stability jádra, je dosti stará myšlenka vlastní zejména mikrokernelům. Navíc je tu ještě předchůdce zvaný LUFS (linux Userland Filesystem). FUSE tuto funkci ale dostává ke skutečným uživatelům řím, že se dobře uchytilo.

Oproti vývoji pro jádro OS má FUSE další výhodu navíc: jeho API bylo portováno na další operační systémy (FreeBSD, NetBSD, OS X, OpenSolaris a další) a jedním kódem tak je možné pokrýt potřeby široké základny uživatelů. Poslední vlastností je pak možnost používat FUSE v uzavřených aplikacích, a to díky licenci GNU LGPL – otevírá se tak možnost dodávat proprietární „ovladač“ souborového systému.

Systém fungování dobře znázorňuje následující obrázek ze stránek projektu.

Připojený souborový systém je pak vidět nejen v /proc/mounts nebo /etc/mtab, ale i jako proces běžící pod uživatelem, který souborový systém připojil. Jedno omezení pro uživatele tu ale stále je: uživatel musí mít přístup k /dev/fuse, což je typicky řešeno přidáním do skupiny fuse.

Místo příkazu mount pak obyčejný uživatel zpravidla spouští přímo program, který souborový systém implementuje, nebo utilitu fusermount. V tomto dílu seriálu se podíváme na pár základních (a dost možná i nejčastěji používaných) souborových systémů přes FUSE.

SSHFS

SFTP, dá se říci, představuje nejsnazší cestu, jak přistupovat k souborovému systému na jiném unixovém stroji kdesi v Internetu. Nevyžaduje zpravidla žádnou složitou konfiguraci, postačují stejné přihlašovací údaje jako bychom u počítače byli fyzicky a protokol je podporován „všude možně“.

Jeden nedostatek to ale má. Pokud bychom chtěli soubory ze vzdáleného systému otevírat, musíme buď soubor nejprve okopírovat na náš systém, nebo se spolehnout na podporu ze strany dotyčné aplikace. V KDE je toto usnadněno pomocí tzv. KIO – snadno tedy v Okularu otevřeme cestu „sftp://server/soubor.pdf“, horší to ale bude kupříkladu s GIMPem. Pokročilejším uživatelům zase může scházet možnost pracovat se soubory z konzole, jako by byly lokální.

Pro řešení tohoto problému je FUSE ideální. Díky rozšířenosti SSH snad ani nepřekvapí, že SSHFS najdeme přímo na domovské stránce FUSE.

Základní připojení souborového systému je prosté:

sshfs lubos@server:/adresar ~/muj-server

Nyní bude v adresáři muj-server v mém domovském adresáři vidět obsah cesty /adresar na serveru server, kam se přihlašuji jako lubos. Určení vzdáleného uživatele a cesty je volitelné. Tím možnosti SSHFS ani zdaleka nekončí – sshfs -h napoví, že program už za sebou má nějakou cestu a počítá s všemožnými nepříjemnostmi.

Nejprve se podíváme na obecnou věc, dostupnou ve všech souborových systémech přes FUSE. Jde o volby allow_other a allow_root, které umožňují přístup k připojenému souborovému systému i jiným uživatelům. Ne, změna práv k adresáři, kam jsme souborový systém připojili, nestačí. Toto je určitá vrstva zabezpečení navíc, i když root může nakonec obejít všechno. Připojovací volby předáváme pomocí -o:

sshfs lubos@server:/adresar ~/muj-server -o allow_other

K základním volbám SSHFS patří reconnect (automatické opětovné navázání spojení) a intr (možnost přerušit probíhající požadavek). Za pozornost stojí i možnost přemapovat UID/GID (čísla uživatelů a skupin) na něco, co bude v kontextu lokálního systému dávat větší smysl. Přímo sshfs na to má volbu idmap, která může mít hodnotu none (výchozí stav, tedy žádné mapování – můžete vidět nesprávná jména uživatelů nebo jen čísla), user (soubory patřící uživateli, pod kterým jsme se přihlásili, budou vypadat jako vlastněné lokálním uživatelem) nebo file (pomocí uidfile a gidfile lze určit mapování detailně). Příklad:

sshfs lubos@server:/adresar ~/muj-server -o idmap=user

FUSE opět nabízí obecné volby (dostupné u všech souborových systémů přes FUSE) uid a gid, se kterými jde vlastníka přemapovat natvrdo. Pro ladění výkonu lze použít různé triky jako cachování v jádře (kernel_cache) nebo povolení velkých bloků při čtení (large_read), opět jde o volby použitelné i pro další souborové systémy.

Na závěr zmiňme ještě volby from_code a to_code. Dnes je sice obvyklé mít všude kódování UTF-8, kdybychom se ale připojovali k systému, kde jsou soubory kódovány v latin2, tak použijeme:

sshfs lubos@server:/adresar ~/muj-server -o from_code=latin2

EncFS

EncFS je taková „entry level“ možnost, jak transparentně šifrovat soubory na počítači. Jádro jako takové nabízí řadu vhodnějších řešení, EncFS nám ale může dát pocit bezpečí i na systémech, kde nejsme rootem. Root se sice bude moci dostat do už připojeného („dešifrovaného“) adresáře, v případě vyhazovu v práci se ale nemusíme strachovat, že by se někdo dodatečně „hrabal“ v našich souborech. (Jak morální je používat techniku zaměstnavatele k ukrývání dat nechme stranou.)

Nejprve je nutné zdůraznit, že EncFS šifruje pouze data v souborech a k tomu pak šifruje názvy souborů. Jiným tak mohou být na odiv některé ostatní údaje jako čas změny nebo velikost souboru. Adresářová struktura tedy zůstává zachována. Ukázka:

$ ls -1 .crypt/WckvGh1c5jwM61u-DTDPWw0Q/
2Q74CtjAF-WXcfNJC7GtkhBn67n5iBH6FimF3k0rUasN1CBhEQz4MSD7odSbFQ3xW8B
4GAC1pvJVJGqAK4p9Bjhq4GG
6UHBALQHZBxTK6JAwIb8mm,q
7TMYTIyLmtu5DwcY,cpDKk4U
apV83SKJc6EbusAooZUsPwOd
h3rhvGUfKVr4-GnYAGt-,,Uu
P5L749LaiTDoIc8iDck3EEXj
q7ZRSGl1lN8mVqUnKeVSTE3a
shHzP0A1C-85uCjuCXvR7FzF
vi9kgALn4q2F3wLLiAIfGJgC

EncFS se používá tak, že máme dva adresáře: první, kde jsou fyzicky uložena zašifrovaná data, a druhý, kde nám EncFS zobrazuje jejich dešifrovanou podobu.

cd

mkdir sifrovane
mkdir desifrovane

encfs sifrovane desifrovane

Při prvním připojení si zvolíme způsob šifrování (buď ručně, nebo se spokojíme s bezpečným výchozím nastavením) a zadáme heslo. Při příštím připojení už budeme dotázáni jen na heslo.

Creating new encrypted volume.
Please choose from one of the following options:
 enter "x" for expert configuration mode,
 enter "p" for pre-configured paranoia mode,
 anything else, or an empty line will select standard mode.
?>
.
.
.
.
New Encfs Password:

S EncFS je přibalen nástroj encfsctl. Ten se dá použít ke změně hesla:

encfsctl passwd sifrovane

Mimo to nám poskytne přehled o atributech aktuálního šifrování:

$ encfsctl info sifrovane
Version 6 configuration; created by EncFS 1.7.4 (revision 20100713)
Filesystem cipher: "ssl/aes", version 3:0:0 (using 3:0:2)
Filename encoding: "nameio/block", version 3:0:0 (using 3:0:1)
Key Size: 256 bits
Using PBKDF2, with 1165023 iterations
Salt Size: 160 bits
Block Size: 1024 bytes, including 8 byte MAC header
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File data IV is chained to filename IV.
File holes passed through to ciphertext.

Zbylé volby encfsctl už nejsou tak zajímavé, odkáži vás tedy na man encfsctl.

Závěr

Na závěr několik obecně užitečných věcí. Odpojování souborového systému:

fusermount -u adresar

Připojování při startu systému (pro uživatele root) – podoba záznamu v /etc/fstab v případě SSHFS:

sshfs#lubos@server:/adresar /nekam/muj-server fuse user,noauto 0 0

Případně, vytvoříme-li si symbolický odkaz z /usr/bin/sshfs na /usr/sbin/mount.sshfs:

lubos@server:/adresar /nekam/muj-server sshfs user,noauto 0 0

       

Komentáře

[tom]

Proprietarni FS se daly psat uz pred FUSE, prislusne API je exportovane pres EXPORT_SYMBOL a ne pres EXPORT_SYMBOL_GPL. Prikladem je treba komerecni Veritas FS.

[Xóža Hňabaj]

Jak se sshfs chová v případě ztráty spojení? Nebude blokovat případné operace nad adresářem, mount, df a spol.?

[rADOn]

Bude a taky to dělá.

[Luboš Doležel (Doli)]

Nastavil bych krátký timeout v SSH a pak už jen -o reconnect.

[snajpa]

Pripadne to jde jenom pro danou session -> -o reconnect,ConnectTimeout=2 (napriklad)

[kolcon]

jo, to je docela otravne... videl jsem kdesi reseni pres autofs

[Tomáš Bžatek]

Tak zrovna GIMP nebyl vhodny priklad, neb je to GTK aplikace, pracujici nad GLib a do nej je externe integrovan GVfs. Takze zrovna otevrit sftp://xxx/ neni v gimpu zadny problem

[Luboš Doležel (Doli)]

Oj. Lepší příklad? Abych to tam nahradil...

[Tomáš Bžatek]

Huh, no neco ne-KDEckoveho a ne-GTKckoveho Treba... paskvil Chromium (nepouzivam, prosim otestovat).

[Tomáš Bžatek]

Klobouk dolu, maintainer reaguje svizne: https://bugzilla.gnome.org/show_bug.cgi?id=679187