question sur la compilation statique

Pas forcément, il suffit de changer l'environnement pour changer le chemin de recherche de la lib. Ca a même un nom: lib spoofing

Mais dans ce cas, il faut déjà être l'utilisateur propriétaire de l'environnement en question (ou propriétaire du .bashrc qui le règle).

C'est aussi pour ça qu'un bon utilisateur *n*x ne met jamais . dans son PATH (et que sous Windows, le répertoire courant est traité en dernier dans la recherche de lib).

L'utilisateur qui exécute

Code:

---

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH application_a_pourrir

---

n'a pas besoin de droits en plus que celui qui exécute l'application.
Du moins, pour ce que j'en sais.

Tu fais ça, tu modifies ton LD_LIBRARY_PATH, dans ta session. Les variables d'environnement ne sont pas partagées, pas même entre deux sessions d'un même utilisateur, c'est pour ça que tout le monde peut les écrire.

Citation:

---

Envoyé par gangsoleil

A l'inverse, dans certains cas, la compilation dynamique est a oublier :

• Probleme de mise a jour des versions : on ne compte plus les bibilotheques qui ne sont pas backward compatibles, et qui s'en foutent. Dans ce cas, un simple update de la bibliotheque, et ton programme ne fonctionne plus.

---

Les bibliothèques correctement développées sont versionnées pour résoudre ce problème.

Citation:

---

• Probleme des libs en matiere de securite : n'importe qui (ou presque) peut remplacer la lib dynamique par une version differente, changeant le comportement. C'est d'ailleurs pour cette raison qu'il n'y a pas (ou qu'il ne devrait pas y avoir) de lib incluant des fonctions de securite (login, cryptographie, ...)

---

On ne doit pas vivre dans le même monde ... avoir des binaires liés statiquement à une bibliothèque contenant des failles de sécurité non patchées n'est pas franchement idéal et alors que seul quelqu'un disposant des privilèges requis peut remplacer une bibliothèque dynamique.