Isso não é uma duplicata porque se trata de uma peculiaridade que notei ao usar o /etc/ld.so.conf.
Para obter os caminhos que o vinculador dinâmico procura nas bibliotecas, executo o comando ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". Quando /etc/ld.so.confnão há caminhos listados nele. A saída do comando anterior é
/lib
/usr/lib
Achei que ele pesquisa /libprimeiro e depois /usr/lib. Quando adiciono um novo caminho, como /usr/local/lib, para /etc/ld.so.confe depois refaço /etc/ld.so.cache, a saída de ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"torna-se
/usr/local/lib
/lib
/usr/lib
Acho isso estranho porque, se estiver certo de que a ordem em que os diretórios listados são pesquisados é de cima para baixo, então diretórios adicionais serão pesquisados antes /libe /usr/lib. O fato de os diretórios adicionais serem pesquisados antes dos diretórios confiáveis não é estranho por si só, mas quando /libé pesquisado antes /usr/lib, isso é estranho porque /bin& /sbiné pesquisado depois de /usr/bin& /usr/sbinem PATH.
Mesmo que os caminhos listados por ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"fossem pesquisados de baixo para cima, ainda assim seria uma ordem distorcida porque diretórios adicionais seriam pesquisados depois dos confiáveis, enquanto /libseriam pesquisados depois de /usr/lib.
Então, qual é a ordem em que ld.soos caminhos das bibliotecas são pesquisados? Por que é /libpesquisado antes /usr/lib? Se não for, por que diretórios adicionais são pesquisados /lib?
Responder1
O pedido está documentado no manual do vinculador dinâmico, que éld.so. Isso é:
- diretórios de
LD_LIBRARY_PATH; - diretórios de
/etc/ld.so.conf; /lib;/usr/lib.
(Estou simplificando um pouco, veja o manual para mais detalhes.)
A ordem faz sentido quando você considera que é a única maneira de substituir uma biblioteca em um local padrão por uma biblioteca personalizada. LD_LIBRARY_PATHé uma configuração do usuário, tem que vir antes das demais. /etc/ld.so.confé uma configuração local, vem antes do padrão do sistema operacional. Portanto, como usuário, se eu quiser executar um programa com uma versão diferente de uma biblioteca, posso executar o programa contendo LD_LIBRARY_PATHa localização dessa versão diferente da biblioteca. E como administrador, posso colocar uma versão diferente da biblioteca /usr/local/libe listar /usr/local/libno /etc/ld.so.conf.
A confiança não entra nisso. Qualquer diretório listado neste caminho de pesquisa deve ser confiável, pois qualquer biblioteca pode acabar sendo carregada a partir daí. Em teoria, você poderia listar os nomes das bibliotecas usadas por todos os programas que “exigem mais confiança” em seu sistema e certificar-se de que todas essas bibliotecas estejam presentes nos diretórios “mais confiáveis”, e então os diretórios “menos confiáveis” não estariam presentes. ser usados se vierem depois dos diretórios mais confiáveis no caminho de busca, exceto para os programas “que exigem menos confiança”. Mas isso seria extremamente frágil. Também seria bastante inútil: se um invasor puder injetar um valor LD_LIBRARY_PATHou um elemento de /etc/ld.so.conf, ele certamente terá uma rota mais direta para executar código arbitrário, como injetar um valor de PATH, de LD_PRELOAD, etc. importa quando a execução cruza um limite de confiança, ou seja, ao executar um programa com privilégios adicionais (por exemplo, programa setuid/setgid ou via sudo). O que acontece neste caso é que LD_LIBRARY_PATHestá apagado.
Quanto a /libvs /usr/lib, não importa muito: eles são fornecidos pela mesma entidade (o sistema operacional) e não deveria haver uma biblioteca presente em ambos. Faz sentido listar /libprimeiro porque fornece uma vantagem de desempenho (muito pequena): as bibliotecas usadas com mais frequência, especialmente as bibliotecas usadas por pequenos programas básicos (para os quais o tempo de carregamento é uma fração maior do tempo total de execução do que grandes e longos programas). -programa em execução), estão localizados em /lib.