Dans quel ordre l'éditeur de liens dynamique de Linux recherche-t-il les chemins?

Ce n'est pas un doublon car il s'agit d'une particularité que j'ai remarquée lorsque j'utilise /etc/ld.so.conf.

Pour obtenir les chemins dans lesquels l'éditeur de liens dynamique recherche les bibliothèques, j'exécute la commande ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". Quand /etc/ld.so.confn'a aucun chemin d'accès répertorié. La sortie de la commande précédente est

/lib
/usr/lib

J'ai pensé qu'il cherche d' /libabord et ensuite /usr/lib. Lorsque j'ajoute un nouveau chemin, tel que /usr/local/lib, /etc/ld.so.confpuis refaire /etc/ld.so.cache, la sortie de ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"devient

/usr/local/lib
/lib
/usr/lib

Je trouve cela étrange parce que si j'ai raison que l'ordre dans lequel les répertoires répertoriés sont recherchés est de haut en bas, alors les répertoires supplémentaires sont recherchés avant /libet /usr/lib. Que les répertoires supplémentaires soient recherchés avant les répertoires de confiance n'est pas étrange en soi, mais quand /libest recherché avant /usr/lib, c'est étrange car /bin& /sbinsont recherchés après /usr/bin& /usr/sbindans PATH.

Même si les chemins répertoriés par ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"étaient recherchés de bas en haut, il s'agirait tout de même d'un ordre biaisé car des répertoires supplémentaires seraient recherchés après ceux de confiance alors /libqu'ils seraient recherchés /usr/lib.

Alors, quel est l'ordre de ld.sorecherche des chemins d'accès aux bibliothèques dans? Pourquoi est /librecherché avant /usr/lib? Si ce n'est pas le cas, pourquoi les répertoires supplémentaires sont-ils recherchés /lib?

L'ordre est documenté dans le manuel de l'éditeur de liens dynamique, qui est ld.so. C'est:

1. répertoires de LD_LIBRARY_PATH;
2. répertoires de /etc/ld.so.conf;
3. /lib;
4. /usr/lib.

(Je simplifie un peu, voir le manuel pour plus de détails.)

L'ordre est logique lorsque vous considérez que c'est le seul moyen de remplacer une bibliothèque dans un emplacement par défaut avec une bibliothèque personnalisée. LD_LIBRARY_PATHest un paramètre utilisateur, il doit précéder les autres. /etc/ld.so.confest un paramètre local, il précède la valeur par défaut du système d'exploitation. Donc, en tant qu'utilisateur, si je veux exécuter un programme avec une version différente d'une bibliothèque, je peux exécuter le programme en LD_LIBRARY_PATHcontenant l'emplacement de cette version de bibliothèque différente. Et en tant qu'administrateur, je peux mettre une autre version de la bibliothèque /usr/local/libet la liste /usr/local/liben /etc/ld.so.conf.

La confiance n'y entre pas. Tout répertoire répertorié sur ce chemin de recherche doit être approuvé, car n'importe quelle bibliothèque pourrait finir par être chargée à partir de là. En théorie, vous pouvez répertorier les noms de bibliothèques utilisés par tous les programmes «nécessitant plus de confiance» sur votre système et vous assurer que toutes ces bibliothèques sont présentes dans les répertoires «les plus fiables», puis les répertoires «moins fiables» ne le seraient pas. être utilisés s'ils viennent après les répertoires les plus fiables sur le chemin de recherche, à l'exception des programmes «nécessitant moins de confiance». Mais ce serait extrêmement fragile. Ce serait également assez inutile: si un attaquant peut injecter une valeur de LD_LIBRARY_PATHou un élément de /etc/ld.so.conf, il a sûrement une voie plus directe pour exécuter du code arbitraire, comme injecter une valeur de PATH, deLD_PRELOAD, etc. La confiance dans le chemin de chargement de la bibliothèque est importante lorsque l'exécution dépasse une limite de confiance, c'est-à-dire lors de l'exécution d'un programme avec des privilèges supplémentaires (par exemple programme setuid / setgid, ou via sudo). Ce qui se passe dans ce cas, c'est qu'il LD_LIBRARY_PATHest masqué.

Quant à /libvs /usr/lib, cela n'a pas beaucoup d'importance: ils sont fournis par la même entité (le système d'exploitation) et il ne devrait pas y avoir de bibliothèque présente dans les deux. Il est logique de répertorier en /libpremier car il offre un (très petit) avantage en termes de performances: les bibliothèques les plus souvent utilisées, en particulier les bibliothèques utilisées par les petits programmes de base (pour lesquels le temps de chargement est une fraction du temps total d'exécution plus longue que les grandes, longues -run programme), sont situés dans /lib.