Aggiorna cache ldconfig senza autorizzazione root

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 

Sto installando diversi binari e librerie localmente, poiché non ho accesso root.

Alcuni programmi devono eseguire il collegamento dinamico a una libreria condivisa in una posizione non standard in fase di esecuzione.

Quando viene eseguito, il programma restituisce:

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

ho percorsi aggiunto alle librerie $LD_LIBRARY_PATH, ma non posso aggiornare la cache ldconfig senza accesso root ...

C'è un dall'utente specifico /etc/ld.so.cache?

O più in generale, è possibile "mascherare" un file di configurazione di sistema con un file di configurazione utente?

Answer 1

La cache di ldconfig si applica solo al percorso specificato in /etc/ld.so.conf o /etc/ld.so.conf.d. Poiché questi non sono scrivibili per utenti non root, non è possibile utilizzarli per migliorare la velocità di avvio per gli eseguibili installati senza autorizzazioni root senza l'aiuto di root (ma anche in questo caso sarebbe una cattiva idea aggiungere un file scrivibile a un utente a questi percorsi di ricerca nella libreria di sistema).

Quindi per questi casi è necessario utilizzare la variabile di ambiente LD_LIBRARY_PATH o rpath/runpath nell'eseguibile o nella libreria che dipende dalle librerie nel percorso non predefinito. Non sono a conoscenza di differenze di velocità tra LD_LIBRARY_PATH e rpath/runpath, ma rpath/runpath hanno il vantaggio di influire solo su eseguibili specifici e quindi hanno meno probabilità di causare problemi ad altri programmi.

In linux/unix non esiste un modo generale per mascherare un file di configurazione del sistema e utilizzare invece un file fornito dall'utente. In effetti, questo è qualcosa che il modello di sicurezza di UNIX deve attivamente impedire di evitare vari tipi di escalation di privilegi. Questo è il motivo per cui anche molte variabili d'ambiente vengono disabilitate per gli eseguibili suid, ad esempio. Molti programmi hanno il loro unico modo per specificare la sovrascrittura della configurazione dell'utente, alcuni più complicati hanno anche modi per l'amministratore di sistema di impostare impostazioni obbligatorie che non sono sovrascrivibili.