Hardlink na adresáře

26.11.2011 18:39 | Přečteno: 3290× | Linux | | poslední úprava: 26.11.2011 21:10

Ve chvíli, kdy jsem viděl (teď už) předposlední xkcd mi bylo jasné, že tohle prostě musím mít! Ale jak na to? Program ln má sice parametr -d, ale i pod rootem vrací EPERM. Takže přece jen ty zdrojáky zas budu muset otevřít.

Takže, co budeme potřebovat? Zdrojáky jádra, včetně funkčního configu, nástroje pro překlad - gcc, binutils, make, virtuální stroj nebo dobré zálohy a odvážného ducha.

A jak na to? Nejdřív by to chtělo zjistit na čem to vlastně chcípá. OK, já vím, že ln volá syscall link ale budeme předstírat, že to nevím. krok 1: strace ln -d /existujici/adresar /novy/hardlink. A po chvilce hledání ve výpisu snad najdete tohle:

linkat(AT_FDCWD, "1", AT_FDCWD, "2", 0) = -1 EPERM (Operation not permitted)

Takže na řadu přichází krok 2: ve zdrojáku najít odpovídající syscall. Hledáme SYSCALL_DEFINE5(linkat (5 protože linkat má 5 parametrů). Najdeme ho ve fs/namei.c:2939 (kernel 3.1.2). Jenže, v té funkci (mimochodem, vědeli jste, že se goto stále používá? :))) ) nic EPERM nevrací. Nabízí se několik možností - vzít debugger, ohackovat to přes printk("prvni test prosel"); nebo si prostě tipnout. No, a zjistíme, že je to ve funkci vfs_link, která je definovaná jen o pár řádků výš :), Konkrétně to jsou řádky 2911 a 2912, s kódem:

if (S_ISDIR(inode->i_mode))
 return -EPERM;

No, a máme jasno, stačí zakomentovat/smazat, překompilovat jádro, rebootovat a jedééém!

root@debian:/mnt# ls -a
.  ..  lost+found
root@debian:/mnt# mkdir prvni
root@debian:/mnt# mkdir druhy
root@debian:/mnt# mkdir prvni/1
root@debian:/mnt# mkdir prvni/2
root@debian:/mnt# ln -d prvni/1 druhy/jednicka
root@debian:/mnt# echo "foo" > prvni/1/testfile
root@debian:/mnt# cat druhy/jednicka/testfile 
foo
root@debian:/mnt# ln -d druhy/ prvni/1/dvojka 
root@debian:/mnt# cd prvni/1     
root@debian:/mnt/prvni/1# ls
dvojka	testfile
root@debian:/mnt/prvni/1# cd dvojka
root@debian:/mnt/prvni/1/dvojka# ls
jednicka
root@debian:/mnt/prvni/1/dvojka# cd jednicka/
root@debian:/mnt/prvni/1/dvojka/jednicka# ls
dvojka	testfile
root@debian:/mnt/prvni/1/dvojka/jednicka# cd /mnt
root@debian:/mnt# # co takhle zkusit treba find?
root@debian:/mnt# find . 
.
./prvni
./prvni/1
./prvni/1/testfile
./prvni/1/dvojka
find: File system loop detected; `./prvni/1/dvojka/jednicka' is part of the same file system loop as `./prvni/1'.
./prvni/2
./lost+found
./druhy
./druhy/jednicka
./druhy/jednicka/testfile
find: File system loop detected; `./druhy/jednicka/dvojka' is part of the same file system loop as `./druhy'.
root@debian:/mnt# # ta mrcha se nezacykli, no co, treba budu mit s e2fsck vetsi stesti
root@debian:/mnt# cd ..
root@debian:/# umount mnt
root@debian:/# e2fsck -f /zerofile 
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'jednicka' in /druhy (1833) is a link to directory /prvni/1 (13).
Clear<y>? no

Entry 'dvojka' in /prvni/1 (13) is a link to directory /druhy (1833).
Clear<y>? no

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/zerofile: ********** WARNING: Filesystem still has errors **********

Mno, takže minimálně pod ext4 to i funguje. Nevím, jak se na to bude tvářit reiserfs, btrfs, xfs nebo jfs, ale snad by s tím nemusel být problém, až bude čas vyzkouším. A mezitím budu přemýšlet, k čemu je to vlastně dobré... :)

Update

Koukám, že je trochu problém s rm:

root@debian:/mnt# rm -rf prvni/
rm: WARNING: Circular directory structure.
This almost certainly means that you have a corrupted file system.
NOTIFY YOUR SYSTEM MANAGER.
The following directory is part of the cycle:
  `prvni/1/dvojka/jednicka'

rm: cannot remove `prvni/1': Directory not empty

Update 2

Hardlink mířící na / skutečně není dobrý nápad. Nejde to unlinknout :)        

Komentáře

[pc2005]

A použiješ je i na stejný účel jako v xkcd?

BTW hardlinkovat adresáře šlo krásně ve FAT. Tam se to někdy i povedlo nechtěně .

Goto v jádře je celkem normálka, v každým modulu jich je několik. Ono když se v sekvenci kontroluje třeba 10 věcí (neNULLový ukazatel na strukturu, návratová hodnota několika registračních funkcí...), tak v případě něčeho jako if, by odsazení v místě po všech kontrolách bylo extrémně vpravo . Nebo by se musely použít funkce, co by to obalily a to by tam bylo zase 10 zbytečných funkcí.

P.S. Grep v MC na .[cSh] a "goto" mě našel zatím 80000 hitů a stále roste .

[Mrkva]

Tak jasně, já to goto chápu :)

[pc2005]

Njn to jsem celý já, vidím požadavek na informaci a hnedka vyhodím data .

[Mrkva]

Mimochodem, ke goto je tu tak jeden hezký strip.

[David Watzke]

True story. Od tý doby koktám

[Bluebear]

Ale vývojáři kernelu mají od svatého Tuxe zvláštní povolení

V kernelu se goto používá jako escape continuation, v podstatě ekvivalent vyhození výjimky. To je ve skutečnosti (IMO) nejlepší způsob, jak výjimečné situace řešit; při množství věcí, které se mohou zku*vit, by skutečně muselo být skoro každé volání funkce obklopené několika úrovněmi if-ů a nevyznalo by se v tom ani to prase.

[kralyk z abclinuxu]

Od toho je ale přece v C longjmp. Nebo snad v klibc longjmp nemají?

[Bluebear]

IMO v rámci jedné funkce je rozumnější použít goto než longjmp; u goto je na první pohled vidět, kam směřuje, je jednodušší udělat uvolnění naalokovaných prostředků, a stack je skoro vždy ve stejném stavu jako předtím, tudíž longjmp je overkill.

[kralyk z abclinuxu]

Jo tak v rámci jedné fce samozřejmě goto, to jo...

[Michal Kubeček]

V C lze goto použít pouze v rámci funkce.

[Michal Kubeček]

při množství věcí, které se mohou zku*vit, by skutečně muselo být skoro každé volání funkce obklopené několika úrovněmi if-ů a nevyznalo by se v tom ani to prase.

Zvlášť při dodržení coding style, který předepisuje odsazování osmiznakovým tabulátorem a limit 80 znaků na řádek. Skalním odpůrcům goto doporučuji si nějakou funkci cvičně zkusit přepsat. Pokud by ani to nepomohlo, tak počkat půl roku a zkusit se v ní zorientovat.

[David Watzke]

Hehe. Na druhou stranu orientovat se v tuně goto taky není úplně jednoduchý.

[Michal Kubeček]

Záleží na způsobu použití. Pokud se používají jen k tomu, k čemu je v jádře obvyklé, tak si myslím, že kód zpřehledňují.

[Kvakor]

Paamtuju, jak jsem přepsáním počátečního cluseru v adrsdářové struktuře FAT udělal disketu, na které bylo podle souborového manageru několik desitek megabytů (limit byl danný maximální délkou cesty v OS). Spolužákovy se to dokonce jednou povedlo udělat nějak omylem a když se to pokusil opravit Scandiskem, o všechna data v postiženém adresáři přišel.

Jinjak ty goto v jádře typicky vypadají takto:

pokus o alokaci prostředku 1;
pokud selže goto 1;

pokus o alokaci prostředku 2;
pokud selže goto 2;

pokus o alokaci prostředku 3;
pokud selže goto 3;

samotná akce;

návěstí 3:
uvolnění prostředku 3;

návěstí 2:
uvolnění prostředku 2;

návěstí 1:
uvolnění prostředku 1;

[Luk]

Jinjak ty goto v jádře typicky vypadají takto

Přesněji takto:

pokus o alokaci prostředku 1;
pokud selže goto konec;

pokus o alokaci prostředku 2;
pokud selže goto uvolni1;

pokus o alokaci prostředku 3;
pokud selže goto uvolni2;

...


uvolni2:
uvolnění prostředku 2;

uvolni1:
uvolnění prostředku 1;

konec:
return;

Je to mnohem čistší a hlavně přehlednější řešení, než kdyby se to dělalo bez goto pomocí vnořených ifů nebo pomocí opakování téhož kódu u každého selhání.

[Sten]

Zlatý jakýkoliv jazyk, který umí výjimky

[Bluebear]

V zásadě bych i souhlasil, jenže kernel je dost specifická oblast.

Výjimky zjednodušují kód jen v případě, že je k dispozici automatické uvolňování prostředků (což si v kernelu neumím moc představit); v opačném případě to stejně musíš někde vyřešit ručně. Přitom je to právě to uvolňování prostředků, co ten kód komplikuje. Kdyby nebylo potřeba nic extra uvolňovat, výjimečné případy by se vyřešily jedním returnem a po ftákách.

Navíc výjimky komplikují práci se stackem, resp. více věcí se děje na stacku mimo dohled programátora, což v kernelu asi taky není to nejlepší.

[Sten]

Operačních systémů napsaných v C++ znám docela dost a výjimky podporují, protože automatické uvolňování prostředků při RAII je velmi jednoduché, při té nejprimitivnější implementaci stačí na stack přidat ukazatele na destruktory, lepší implementace mívají stacky dva. Dokonce to ani nepotřebuje plné RTTI, stačí upcast pro třídy výjimek (a v jádře by asi nebylo potřeba ani to, když stačí errno). V podstatě kompilátor jenom vytvoří něco podobného těm goto automaticky, díky čemuž není problém ani s orientací na stacku. Výjimky dokonce nejsou ani pomalejší, díky tomu, že víc věcí dělá kompilátor, tím lépe to zvládne optimalizovat. Když se podívám na implementaci výjimek v LLVM libstdc++ nebo GNU libstdc++, tak jediné, co je skutečně potřeba, je jazyk, který výjimky podporuje. Na druhou stranu chápu, proč v roce 1991 zvolil Linus C, tehdejší implementace výjimek byly strašné.

[Grunt]

Abych pravdu řekl, já

if (find ("goto", kod))
  body -= 2;

nikdy nepochopil a vždy jsem to bojkotoval. Já bohužel pamatuju ještě doby BASICu a pamatuju, že ani s GOTO a GOSUB to nebylo tak strašné když to nepsalo prase, které se v tom samo nezamotalo. Tendenci vnucovat programátorovi jak má psát a snažit se ho vyučovat jsem též nikdy nepochopil. Aneb nač dělat věci jednoduše, když si to můžeme zasvinit konstruktorama, destrukotama, excepšnama a bůh ví čím ještě. Vždyť GOTO se velice snadno dá přeložit na jmp instrukci, jednu z nejpřirozenějších instrukcí procesoru.

[Michal Kubeček]

No, ono když vidíte v kódu něco na způsob

  if (problém)
    goto label2;

  ...

label1:
  úklid
  return 0;

label2:
  něco
  goto label1;
}

tak na vás přímo dýchne tak doba BASICu na osmibitech…

[pc2005]

To jako, že je v jádře goto label1 navíc (kdyby byl label2 před label1, tak se plynule přejde)? Možná to je kvůli ladění.

[Michal Kubeček]

Tohle není kód vanilla jádra, tenhle obrat jsem viděl v jednom modulu, který ve vanilla jádře není. Prohodit pořadí nejde, protože to, co je za label2, se nemá vykonat, pokud k němu dojdete přirozenou cestou nebo na něj skočíte odjinud. Správně by to mohlo být třeba takto:

  if (problém) {
    něco
    goto label1;
  }

  ...

label1:
  úklid
  return 0;
}

Ale i v upstreamových projektech se občas najdou strašidelné věci. Máte-li dobrý žaludek, můžete zkusit prozkoumat třeba funkci send_dg() v implementaci resolveru v glibc.

[Tomáš]

Myslím, že Mac to používá kvůli zálohování pomocí Time Machine. Je s tím spousta omezení a normálnímu smrtelníkovi ta funkce není přístupná. Přeci jenom není lepší věc, než zacyklení mezi adresáři.

[Michal Kubeček]

IMHO existuje spousta jednodušších způsobů, jak si rozbít filesystém…

[Mrkva]

Ale on se nerozbil!

[Michal Kubeček]

Ano, nerozbil se, rozbil jste si ho vědomě sám. :-) (Pokud to snad nebylo jasné z minulého příspěvku, tak zacyklené adresáře považuji za rozbitý filesystém.)

[Mrkva]

Tak nikdo vás nenutí tam ty cykly vytvářet :)

[marbu]

A mezitím budu přemýšlet, k čemu je to vlastně dobré... :)

Jako hracka vazne dobre :) Ale realne pokud potrebujes hardlink na adresar, resilo by se to pomoci bind mount:

mount --bind /kdesi/cosi /nekde/jinde/cosi

.

[pavlix]

A to právě nemá s hardlinkem nic moc společného (přesněji řečeno asi tolik co se symlinkem). Navíc vzhledem k odkazu na XKCD je celkem jasné, o co tu jde :).

Mount --bind používejte opatrně, symlinky jsou ve většině případů stejně použitelné a mnohem bezpečnější (rm -rf končí symlinkem).

[Sten]

mount --bind neprochází přes mountpointy, takže nikdy nemuže vytvořit nekonečnou smyčku.

[pavlix]

Zajímavé. Prakticky ověřeno.

[Tyf]

Existuje i mount --rbind. Ale zacykleni jsem nezkousel.

[Sten]

rbind to sice nabinduje rekurzivně, ale před tím bindem, takže cyklus to pořád nevytvoří:

/
  [/bind je prázdné]
  /home
  /var

rbind / do /bind:
/
  /bind
    [/bind/bind je prázdné]
    /bind/home
    /bind/var
  /home
  /var

[nyan]

Ja nikdy nepochopil *proc* nejde udelat hardlink adresaru. Vsude rikaji ze nejde... a nikde sem nevidel opravdove vysvetleni.

[Michal Kubeček]

Např. by pak byl problém s položkou "..", která má odkazovat na rodiče. Jenže tady by těch rodičů bylo víc, takže byste si musel některého vybrat, což zase bude dělat problémy, když zrovna tu adresářovou položku, jejíž to byl rodič, smažete.

[Mrkva]

Např. by pak byl problém s položkou "..", která má odkazovat na rodiče. Jenže tady by těch rodičů bylo víc, takže byste si musel některého vybrat

IMHO, vzhledem k tomu, že nic jako ".." ve FS ani není je to irelevantní - systém to vygeneruje na základě cesty, takže tenhle problém odpadá.

což zase bude dělat problémy, když zrovna tu adresářovou položku, jejíž to byl rodič, smažete.

No, zatím jsem nepřišel na to, jak odstranit hardlink na adresář bez smazání obsahu :)

[Michal Kubeček]

IMHO, vzhledem k tomu, že nic jako ".." ve FS ani není je to irelevantní - systém to vygeneruje na základě cesty, takže tenhle problém odpadá.

Co prosím? Neusuzujte, prosím, jen na základě toho, jak se (defaultně) chová příkaz cd v bashi.

zatím jsem nepřišel na to, jak odstranit hardlink na adresář bez smazání obsahu

To není až tak překvapivé, vzhledem k tomu, že se s jejich existencí nepočítá. Musel byste si opatchovat syscall rmdir() nebo unlinkat() a když se zamyslíte jak, zjistíte, že není úplně triviální udělat to tak, aby to fungovalo.

[Ondrej 'SanTiago' Zajicek]

Ono to nejde asi hlavne proto, aby se zachovaly dobre strukturalni vlastnosti filesystemu. Proste je mnohem vyhodnejsi predpokladat, ze adresare tvori strom a diky tomu zjednodusit spoustu algoritmu, nez povolit hardlink adresaru a vsechno implementovat s predpokladem, ze adresare tvori obecny graf.

[perdy]

Kaslat na GOTO, skutocny muz pouzije COMEFROM.Samozrejme spolu s dalsimi ficurami INTERCALu, coz je skvela parodia na programovaci jazyk.

[linux_enthusiast]

Hmmmm, pekná debata sa tu okolo toho rozbehla. Nieže by sa mi nechcelo hrať sa s jadrom, ale nechcem riskovať pád systému. Som rád, že mám Linux stabilný (veď za to ho už 3 roky používam) a nechcem riskovať nejakým blbým preklepom jeho pád.

[linux_enthusiast]

Tak ma teraz napadlo. keď chcem, aby sa mi spustil môj shell script pri otvorení konkrétneho adresára, kde to mám zapísať?