Zaktualizuj pamięć podręczną ldconfig bez uprawnień administratora

Question

$ uname -a 
Linux xhost10.bcgsc.ca 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux 

$ /sbin/ldconfig --version 
ldconfig (GNU libc) 2.5 

Instaluję lokalnie kilka plików binarnych i bibliotek, ponieważ nie mam uprawnień administratora.

Niektóre programy muszą dynamicznie łączyć się z biblioteką współdzieloną w niestandardowej lokalizacji w środowisku wykonawczym.

Po uruchomieniu, program powraca:

$ path/to/cc1 
path/to/cc1: error while loading shared libraries: libmpc.so.3: cannot open shared object file: No such file or directory 

Dodałem ścieżki do bibliotek $LD_LIBRARY_PATH, ale nie mogę zaktualizować cache ldconfig bez dostępu do korzeni ...

Czy istnieje dla użytkownika specyficzne /etc/ld.so.cache?

Czy ogólnie można "zamaskować" plik konfiguracji systemu za pomocą pliku konfiguracyjnego użytkownika?

Answer 1

Pamięć podręczna ldconfig dotyczy tylko ścieżki określonej w /etc/ld.so.conf lub /etc/ld.so.conf.d. Ponieważ nie są one dostępne do zapisu dla użytkowników niebędących rootami, nie można ich użyć do zwiększenia szybkości uruchamiania plików wykonywalnych bez uprawnień root bez pomocy root'a (ale nawet wtedy niewłaściwym pomysłem byłoby dodanie pliku do zapisu dla użytkownika systemowa biblioteka wyszukiwania pathes).

Tak więc w tych przypadkach należy użyć zmiennej środowiskowej LD_LIBRARY_PATH lub ścieżki rpath/runpath w pliku wykonywalnym lub bibliotece, która zależy od bibliotek w ścieżce innej niż domyślna. Nie jestem świadomy jakichkolwiek różnic prędkości między LD_LIBRARY_PATH i rpath/runpath, ale rpath/runpath mają tę zaletę, że wpływają tylko na określone pliki wykonywalne, a zatem są mniej prawdopodobne, że spowodują problemy dla innych programów.

W systemie Linux/Unix nie istnieje ogólny sposób zamaskowania pliku konfiguracji systemu i użycia pliku dostarczonego przez użytkownika. W rzeczywistości jest to coś, o czym musi zapobiegać model zabezpieczeń unix, aby uniknąć różnego rodzaju eskalacji uprawnień. To jest powód, dla którego nawet wiele zmiennych środowiskowych jest wyłączonych na przykład dla plików wykonywalnych suid. Wiele programów ma jeden sposób na określenie nadpisującej konfiguracji użytkownika, niektóre bardziej skomplikowane mają również sposoby, aby administrator systemu ustawiał obowiązkowe ustawienia, które nie mogą zostać zmienione.