Dotaz: Problém s linkováním knihoven

[Dave]

Ahoj, mám takový podivný problém s linkováním knihoven. Spouštím vlastní build Apache (resp. build, který vytvořil jiný člověk a já ho musím používat):

~/apache-2.4.3-29/bin> ./httpd

a dostávám tuto chybu:

./httpd: error while loading shared libraries: libaprutil-1.so.0: cannot open shared object file: No such file or directory

přitom

~/apache-2.4.3-29/bin> echo $LD_LIBRARY_PATH
/home/dave/apache-2.4.3-29/lib
~/apache-2.4.3-29/bin> ls -l /home/dave/apache-2.4.3-29/lib/libaprutil*.so
lrwxrwxrwx 1 root root     21 led 16 15:11 /home/dave/apache-2.4.3-29/lib/libaprutil-1.so -> libaprutil-1.so.0.4.1
lrwxrwxrwx 1 root root     21 led 16 15:11 /home/dave/apache-2.4.3-29/lib/libaprutil-1.so.0 -> libaprutil-1.so.0.4.1
-rwxr-xr-x 1 root root 345171 led 16 15:11 /home/dave/apache-2.4.3-29/lib/libaprutil-1.so.0.4.1

Když spustím program jako root, tak linkování funguje správně. Kde může být problém?

---

---

Odpovědi

[Pavel Stárek]

Jen tak pro zajímavost, co vypíše ldd ./httpd ?

[Dave]

Aha, to jsem zapomněl připojit, ldd se tváří, že je vše v pořádku...

~/apache-2.4.3-29/bin> ldd ./httpd
	linux-gate.so.1 =>  (0xffffe000)
	libpcre.so.0 => /home/dave/apache-2.4.3-29/lib/libpcre.so.0 (0xf7707000)
	libaprutil-1.so.0 => /home/dave/apache-2.4.3-29/lib/libaprutil-1.so.0 (0xf76ec000)
	libexpat.so.0 => /home/dave/apache-2.4.3-29/lib/libexpat.so.0 (0xf76cd000)
	libapr-1.so.0 => /home/dave/apache-2.4.3-29/lib/libapr-1.so.0 (0xf76a6000)
	librt.so.1 => /lib/librt.so.1 (0xf768a000)
	libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7654000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xf7639000)
	libdl.so.2 => /lib/libdl.so.2 (0xf7634000)
	libc.so.6 => /lib/libc.so.6 (0xf74c7000)
	/lib/ld-linux.so.2 (0xf7715000)

[Pavel Stárek]

Vskutku, to vypadá, že je to ok. Nicméně, nechybí něco té knihovně libaprutil-1.so.0? Tedy zase zkusit ldd libaprutil-1.so.0.

[Dave]

Bohužel, ani tudy asi cesta nevede:

~/apache-2.4.3-29/bin> ldd /home/dave/apache-2.4.3-29/lib/libaprutil-1.so.0
	linux-gate.so.1 =>  (0xffffe000)
	libexpat.so.0 => /home/dave/apache-2.4.3-29/lib/libexpat.so.0 (0xf76c2000)
	libapr-1.so.0 => /home/dave/apache-2.4.3-29/libapr-1.so.0 (0xf769c000)
	librt.so.1 => /lib/librt.so.1 (0xf7680000)
	libcrypt.so.1 => /lib/libcrypt.so.1 (0xf764a000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xf762e000)
	libdl.so.2 => /lib/libdl.so.2 (0xf7629000)
	libc.so.6 => /lib/libc.so.6 (0xf74bc000)
	/lib/ld-linux.so.2 (0xf76fd000)

[Pavel Stárek]

Tak pak už nevím. Jedině zdali není spuštěn SElinux nebo AppArmor a nějak tomu nebrání.

[Dave]

Hmm, já už taky nevím Ale díky za snahu. SELinux zapnutý není...

[dustin]

Pokud pod rootem ty knihovny najde, pak je problém v právech. Tipuji si, že binárku spouštíš pod uživatelem, který nemá přístup do toho homu /home/dave. Spouštíš binárku pod rootem? Apache se po obsazení privilegovaného portu 80 přepíná na neprivilegovaného uživatele (www-data v debianu), není problém v tom, že tento uživatel právo čtení na soubory v /home/dave nemá?

[Dave]

To už jsem kontroloval. Uživatel má přístup do všech adresářů. Coby uživatel dave vidím obsah té knihovny, která se nemůže přilinkovat...

Apache chci záměrně spustit jako obyčejný uživatel, problém s privilegovaným portem řeším pomocí setcap. Ale problém je, že httpd se nepovede asi slinkovat, natož spustit...

[Michal Vyskočil]

Zkus spustit strace -f -eopen -o httpd.strace ./httpd a prozkoumat httpd.strace.

[Dave]

Díky za tip. Z strace logů vyplývá, že linker se do adresáře /home/dave/apache-2.4.3-29/lib ani nesnaží dívat - není tam jediný záznam s tímto adresářem. Ale proč, když mám LD_LIBRARY_PATH nastavenou?

[jekub]

a exportovanou?

[Dave]

jj, exportovanou...

[Punny]

zkusil bych mozna:

export LD_LIBRARY_PATH=/home/dave/apache-2.4.3-29/lib:$LD_LIBRARY_PATH

a jeste mozna mrknout do /etc/ld.so.conf
Punny

[Dave]

LD_LIBRARY_PATH už exportovanou mám. A v /etc/ld.so.conf jsou jenom dva systémové adresáře /usr/local/lib64 a /usr/local/lib... Nejde mi do hlavy, proč to nefunguje...

[rADOn]

A kdyz to vynutis pres LD_PRELOAD ?

[Dave]

S LD_PRELOAD dostanu toto:

ERROR: ld.so: object '/home/dave/apache-2.4.3-29/lib/libaprutil-1.so.0' from LD_PRELOAD cannot be preloaded: ignored.

[Sten]

Nemá httpd nastaveno setuid nebo setgid? Linker potom LD_LIBRARY_PATH ignoruje.

[Dave]

Díky za další nápad, nemá. To už jsem kontroloval, má klasická práva 755.

[Ivan]

A nemas tu cestu nejak divne zakompilovanou do ty binarky? (-Wl,-rpath=...). Zkus:

readelf -d ./httpd | grep RPATH

Ta cesta muze byt absolutni (/home/dave.../) anebo relativni ($ORIGIN/...).

Jeste muzes zkusit tohle

LD_TRACE_LOADED_OBJECTS=1 ./httpd

PS: ty mas vlastni i knihovne pcre? Neni mozny, ze se ti nahraje nejdrive tahle knihovna ze sytemu a ta si pak vezme i systemovy libapr (libaprutil).

[ET]

ldconfig
~/apache-2.4.3-29/bin/httpd

popr. sem postni cely strace ;)

[Dave]

Tak jsem se posunul trochu dál, ale je to pro mě čím dál tím větší záhada.

Zjistil jsem, že pokud binárku httpd zduplikuju do jiného souboru příkazem

cp httpd httpd1

tak ze v pořádku spustí!

Pokud ale použiju

cp -a httpd httpd2

tak binárka zahlásí chybu s linkováním libaprutil-1.so.0. Čím by to mohlo být? Na filesystému je zapnuté ACL, ale na httpd není ACL použité...

> getfacl httpd 
# file: httpd
# owner: root
# group: root
user::rwx
group::rwx
other::rwx

[pavlix]

Porovnání výstupu ldd by bodlo. Btw, nemáš tam nějakou mandatory access control jako selinux, apparmor apod?

[Dave]

Porovnání výstupu ldd je jednoduché - pro funkční i nefunkční binárku je výstup z ldd identický, linker všechny knihovny najde. SELinux ani nic podobného v systému není... Začíná to pomalu vypadat jako nějaká chyba filesystému...?

[pavlix]

Jo vidíš to...

Pusť na ten httpd příkaz file.

[Ivan]

spust to s LD_TRACE_LOADED_OBJECTS LD_VERBOSE LD_DEBUG a postni vypis.

[Ivan]

Napr:

~: LD_DEBUG=libs ./a.out
     25201:     find library=libstdc++.so.6 [0]; searching
     25201:      search cache=/etc/ld.so.cache
     25201:       trying file=/usr/lib64/libstdc++.so.6
     25201:
     25201:     find library=libm.so.6 [0]; searching
     25201:      search cache=/etc/ld.so.cache
     25201:       trying file=/lib64/libm.so.6
     25201:
     25201:     find library=libgcc_s.so.1 [0]; searching
     25201:      search cache=/etc/ld.so.cache
     25201:       trying file=/lib64/libgcc_s.so.1
     25201:
     25201:     find library=libc.so.6 [0]; searching
     25201:      search cache=/etc/ld.so.cache
     25201:       trying file=/lib64/libc.so.6
     25201:
     25201:
     25201:     calling init: /lib64/libc.so.6
...
 

[Dave]

S LD_TRACE_LOADED_OBJECTS se nevypíš vůbec nic:

> LD_TRACE_LOADED_OBJECTS=1 ./httpd
>

U ostatních proměnných se vypíše jen stará známá chyba linkování...

> LD_VERBOSE=1 ./httpd
./httpd: error while loading shared libraries: libaprutil-1.so.0: cannot open shared object file: No such file or directory
> LD_DEBUG=all ./httpd
./httpd-error: error while loading shared libraries: libaprutil-1.so.0: cannot open shared object file: No such file or directory
>

[rADOn]

> getfacl httpd 
# file: httpd
# owner: root
# group: root
user::rwx
group::rwx
other::rwx

O kus vyse jsi tvrdil ze apac ma 755, ale tohle je podle me 777. A 777 binarka rozhodne neni normalni, nemas tam jeste jinde pomrveny prava?

[Dave]

Ze zoufalství už jsem si různě hrál s přístupovými právy. Ale stejné chování je i u těch původních souborů, které opravdu mají 755...

[rADOn]

A není na tom souboru rozšířenej atribut (viz lsattr/chattr)? Další nápad: když místo cp -a použiješ mv tak to udělá co?

[Dave]

Výpis atributů je u obou binárek stejný:

> lsattr -a
-------------e- ./httpd-error
-------------e- ./httpd-ok

mv binárku nezmění - funkční zůstane funkční, nefunční po přejmenování stále nefunguje.

[dustin]

Asi velice hloupá otázka - není to httpd symlink? Že se to chová jinak po tom cp -a

[pavlix]

Jistota je jistota...

[dustin]

No právě, viz minulá diskuse o aliasu. Ten mi taky napadl, ale říkal jsem si, že to by byla ptákovina. A ono jo :)

[Dave]

Díky i za hloupé otázky Třeba je to jen nějaká blbost, kterou přehlížím. Ale symlink to není. Jsou to binárky, cmp je označuje jako identické.

[Michy]

To opravdu vypadá na problém s právy. Soubory httpd, httpd1 a httpd2 vzniklé cp httpd httpd1 a cp -a httpd httpd2 se budou lišit skoro jistě pouze v právech (a v časech). Jak vypadá výstup ls -l httpd httpd? ?

[Dave]

ls neukazuje žádné rozdíly. Binárky jsem přejmenoval, aby bylo jasné, která je která...

-rwxrwxrwx 1 root root 1311555 kvě 23 12:17 httpd-error
-rwxrwxrwx 1 root root 1311555 kvě 23 12:17 httpd-ok

[rADOn]

1.3 mega? W.T.F.? U mě v gentoo i na debianu má binárka apače (2.2.22) třetinovou velikost. Určitě je tam zakompilený něco co dělá bordel… ale co by se mohlo projevovat takhle podivně je mi záhadou. Můžeš nám nějak osvětlit co to je za binárku (pokud nevíš, přepínač -l na funkční verzi by leccos osvětlil). Případně ten balík někam postnout?

[Dave]

Compiled in modules:
  core.c
  mod_so.c
  http_core.c

Binárka je nestripovaná, proto asi ta velikost. Vystavit ji nemůžu, jedná se o firemní projekt, který nemůžu šírit.

[Michy]

Tomu skoro nemůžu uvěřit. Soubor httpd-error vzniklý příkazem cp -a httpd httpd-error a soubor httpd-ok vzniklý příkazem cp httpd httpd-ok by měly mít přinejmenším rozdílný ctime (čas poslední modifikace). Soubor httpd-error by měl mít čas stejný jako ten původní httpd, zatímco soubor httpd-ok bude mít čas toho okamžiku, kdy vznikl příkazem cp. To, že mají oba stejný čas, svědčí o tom, že něco děláš špatně nebo přinejmenším ne tak, jak naznačuješ.

[Dave]

Máš samozřejmě pravdu. Zkoušel jsem mezitím na binárkách touch, jestli bude mít nějaký efekt. A neměl... Před touchem měl soubor httpd-error čas modifikace původního httpd.

[Ed]

Zkus zmenit jmeno souboru. Pokud to httpd *jen* prejmenujes, zacne to fungovat? To by totiz naznacovalo, ze na vine je AppArmor.

[Dave]

AppArmor na systému není. Přejmenování binárky nemá vliv na její funkčnost/nefunkčnost...

[rastos]

Len tak pre zaujímavosť: aký filesystém je tam použitý?

[Dave]

Filesystém je ext4, mountovaný je s parametry acl a user_xattr.

[Michy]

Všechno nasvědčuje tomu, že problém je v právech/atributech té spouštěné binárky. Příkaz cp -a zachovává všechny atributy a takto získaný soubor nefunguje, zatímco samotný cp všechny atributy nezachová, a potom ta binárka spustit jde. Zaměř se tedy na to, v jakých atributech se ty soubory liší.

Zradu bych tušil třeba v tom, že domovský adresář (/home/dave) má nejspíš omezený přístup pro uživatele, pod kterým tu binárku spouštíš. Ale to jen tak střílím od boku, s tím už se musíš poprat sám...

[Dave]

Zaměř se tedy na to, v jakých atributech se ty soubory liší.

No to tu řeším celou dobu, ale všechny porazené příkazy ukazují, že atributy binárek jsou naprosto shodné... Přístupovými právy do adresářů to taky nebude, zkoušel jsem to v různých, i v tempu... Prostě už nevím...

[Michy]

A getfattr jsi zkoušel?

[Dave]

Vypadá to, že binárky žádné rozšířené atributy nastavené nemají - getfattr dává na všech binárkách prázdný výstup.

[Milan Roubal]

cp -a

se da rozepsat jako

cp -dR --preserve=all

kde parametr preserve ma tyto volby.

 --preserve[=ATTR_LIST]
	      preserve	 the   specified   attributes	(default:  mode,owner-
	      ship,timestamps), if possible  additional	 attributes:  context,
	      links, xattr, all

pokud vyzkousis vsechny moznosti, ktera z tech voleb zpusobi tuto chybovou hlasku?

BTW jak se ten soubor vubec na ten filesystem dostal? Byl tam vytvoren pomoci make, zkopirovan odnekud, ..?

[beer]

Co tohle:

cp httpd httpd1 mv httpd1 httpd

[beer]

cp httpd httpd1

mv httpd1 httpd

[Ed]

Jeste me napada - jste si jisty, ze spoustite httpd z aktualniho adresare?

[Dave]

Ano. Binárky se chovají stejně, ať už je spouštím s relativní nebo absolutní cestou...

[chochi]

Neco podobneho mi delal selinux (podobne by se mela chovat set-uid binarka). Zkus co udela:

LD_SHOW_AUXV=1 ./httpd

Pak by byl zajimavy cely strace:

strace -f ./httpd

Respektive zda se v nem nevyskytuje neco jako "/etc/suid-debug".

[rADOn]

Tak jsem se konečně k něčemu dobral. Zjistil jsem, že za problémem stojí capabilities. Pokud souboru nastavím capability:

/sbin/setcap cap_net_bind_service=+ep ./httpd

tak neumí přilinkovat knihovnu libaprutil-1.so.0 a nespustí se. Pokud ale capability odeberu, binárka spustit jde.

Ale proč? A jak to vyřešit?

[chochi]

Jo, tak nastaveni capabilities dela to same co set-uid. Reseni je nepouzivat LD_LIBRARY_PATH, protoze je ignorovano. Spravna cesta je nastavit ty adresare kde se maji hledat knihovny do /etc/ld.so.conf (respektive do necoho z ceho se to generuje - zalezi na distribuci) a pustit ldconfig.

[Dave]

No sláva! Přidal jsem konfigurační soubor s cestou ke knihovnám do /etc/ld.so.conf.d/, spustil ldconfig, a ono to jede! Díky moc za pomoc všem zúčastněným .

[rastos]

Zjistil jsem, že za problémem stojí capabilities.

Klobúk dole, že si to nevzdal a dopátral sa k príčine.

Teraz aspoň vieš, čo máš teraz hľadať a snáď niečo užitočné nájdeš.

Btw, kde sa capabilities ukladajú? Do inode-u? V tom prípade by sa patrilo, aby ich stat zobrazil, nie?

[Milan Roubal]

Tak jsem se rozhlednul po webu a podpora pro capabilities v zakladnich utilitach jako je ls, cp, tar, cpio, rsync etc. je rozdilna. U kazde utility se ten parametr jmenuje jinak a pokud nainstalovana verze uz tu funkcionalitu podporuje, jsou obcas potreba pridat parametry 3, jeden pro capabilities, dalsi pro extended attributes a dalsi pro ACL. Nevite nekdo o peknem clanku, ktery by situaci pro capabilities, extended attributes a ACL shrnoval?

[Milan Roubal]

odpovim si sam, shrnuti je k nalezeni zde