리눅스에서 LD_LIBRARY_PATH의 올바른 사용법, 위험성 및 대안

인포 마텍 디지털 » 자료 » Linux의 LD_LIBRARY_PATH: 올바른 사용법, 위험 및 대안

LD_LIBRARY_PATH 는 누구나 한 번쯤은 접하게 되지만, 제대로 이해하는 사람은 드물고, 무엇보다 잘못 사용되는 경우가 많은 리눅스 환경 변수 중 하나입니다. 공유 라이브러리 문제, 실행되지 않는 파일, 또는 자체 라이브러리가 필요한 애플리케이션과 같은 문제에 직면했을 때 이 변수 ​​이름이 자주 등장합니다.

이 글에서는 LD_LIBRARY_PATH가 무엇인지, 동적 로더가 내부적으로 어떻게 작동하는지 , 이 변수를 사용하는 것이 적절한 경우와 사용하지 않는 것이 더 나은 경우를 살펴보겠습니다. 우분투와 같은 배포판의 실제 예시를 통해 (거의 모든 배포판에 적용 가능) 올바르게 설정하는 방법을 설명하고, 이 변수를 사용자 프로필에 영구적으로 연결하는 것보다 훨씬 깔끔하고 안전한 대안도 검토해 보겠습니다.

LD_LIBRARY_PATH는 무엇이며 실제로 어떤 용도로 사용되는가?

최신 GNU/Linux 시스템에서 대부분의 프로그램은 다음과 같은 링크로 연결됩니다. 공유 라이브러리 실행 파일이 시작될 때 메모리에 로드되는 (.so 파일) 라이브러리입니다. 런타임에 이러한 라이브러리를 찾는 역할을 하는 구성 요소는 다음과 같습니다. 다이내믹 충전기 (보통 ld.so 또는 다음과 같은 변형 ld-linux-x86-64.so.2 (건축 양식에 따라)

환경 변수 LD_LIBRARY_PATH는 디렉터리 목록을 정의합니다. 프로그램이 실행될 때 동적 로더가 공유 라이브러리를 찾을 위치입니다. 콜론으로 구분된 목록이며, 예를 들면 다음과 같습니다. /ruta/uno:/ruta/dos:/otra/ruta그리고 그것은 자문을 구하는 대상입니다. 표준 경로 이전 시스템의 /lib o /usr/lib.

즉, LD_LIBRARY_PATH에 있는 라이브러리와 시스템 디렉터리에 있는 라이브러리의 이름이 같을 경우, 로더는 LD_LIBRARY_PATH에 있는 라이브러리를 우선적으로 사용합니다 . 이것이 바로 강력한 기능이지만, 부주의하게 사용하면 많은 문제를 야기하는 원인이기도 합니다.

이 메커니즘은 Nix 계열 환경, 사용자 디렉터리에 설치된 라이브러리, 사용자 지정 버전의 라이브러리 또는 시스템 라이브러리에서 가져오지 않으려는 자체 종속성으로 패키징된 애플리케이션과 같이 표준이 아닌 라이브러리 경로를 사용할 때 특히 유용합니다 .

LD_LIBRARY_PATH의 일반적인 사용 사례

LD_LIBRARY_PATH를 사용하는 것은 매우 특수하고 통제된 시나리오 에서 의미가 있습니다 . 이러한 경우에만 사용한다면 매우 유용한 도구이지만, 모든 것에 기본 솔루션으로 사용한다면 조만간 문제가 발생할 수 있습니다.

가장 흔한 용도 중 하나는 다음과 같습니다. 공유 라이브러리의 새 버전을 사용해 보세요. 시스템 라이브러리를 건드리지 않고 미리 컴파일된 애플리케이션을 대상으로 테스트하는 것입니다. 예를 들어, 개발 버전을 만든 경우입니다. libmylib.so 홈 디렉터리에서 LD_LIBRARY_PATH를 조정하여 테스트 세션에서만 해당 라이브러리를 사용하도록 할 수 있습니다.

또 다른 매우 흔한 시나리오는 이전 버전을 보존하기 위해 라이브러리를 재배치하는 것 입니다 . 예를 들어, 레거시 애플리케이션에 대해서는 이전 버전의 라이브러리를 유지하고 시스템의 나머지 부분에서는 최신 버전을 사용하고 싶다고 가정해 보겠습니다. LD_LIBRARY_PATH를 사용하면 해당 애플리케이션이 이전 버전이 저장된 디렉터리를 가리키도록 지정할 수 있습니다.

또한 대규모 애플리케이션을 위한 독립형 및 재배치 가능한 환경을 설정하는 데 자주 사용되며 , 이 경우 공급업체는 시스템 라이브러리에 의존하지 않고 자체 라이브러리를 폴더 내에 패키징합니다. 이러한 경우 일반적으로 시작 스크립트가 LD_LIBRARY_PATH를 조정하여 애플리케이션이 항상 자체 .so 파일을 로드하도록 합니다.

이 모든 경우에 핵심은 LD_LIBRARY_PATH가 사용자가 실행하는 모든 프로그램이나 시스템 전체에 영향을 미치는 전역 변수가 아니라 특정 애플리케이션이나 테스트 환경과 연관되어 제한적이고 특정한 방식으로 사용된다는 점입니다.

리눅스에서 LD_LIBRARY_PATH를 단계별로 설정하는 방법

위험을 알면서도 여전히 원하시네요. 사용자 환경 변수에 LD_LIBRARY_PATH를 정의하십시오.우분투와 같은 배포판에서는 해당 파일을 편집하는 것이 일반적입니다. ~/.bashrc (Bash를 기본 셸로 사용한다고 가정할 때) 이 파일은 새 대화형 터미널을 열 때마다 실행됩니다.

먼저 파일을 여세요. 선호하는 편집기로 .bashrc 파일을 열어보세요.많은 튜토리얼에서 사용됩니다. nano 간단하게 설명하기 위한 것이지만, 다음과 같이 해도 됩니다. vi, vim 또는 텍스트 편집기:

나노 ~ / .bashrc

파일을 열면 변수를 설정하는 내보내기 줄을 추가 해야 합니다 . 여기서 중요한 것은 등호(=) 주위에 공백을 두지 않는 것입니다. 그렇지 않으면 Bash가 잘못 해석합니다. 올바른 예는 다음과 같습니다.

export LD_LIBRARY_PATH=/home/osboxes/mukul

이 경우, 시스템이 공유 라이브러리를 검색할 때 표준 디렉터리보다 /home/osboxes/mukul 디렉터리를 먼저 고려하도록 지시하는 것입니다 . 이 부분을 사용자 지정 .so 파일 또는 사용하려는 라이브러리의 경로로 바꿀 수 있습니다.

변경 사항을 저장하고 편집기를 종료한 후에는 새 환경 변수가 현재 세션에 적용되도록 셸 구성을 다시 로드 해야 합니다 . 일반적으로 다음 명령을 사용하여 수행합니다.

소스 ~ / .bashrc

모든 설정이 올바르게 적용되었는지 확인하려면 다음 명령어를 사용하세요. echo 해당 변수에 대해 설명드리겠습니다. 다음은 LD_LIBRARY_PATH에 현재 포함된 경로들을 보여줍니다.

echo $LD_LIBRARY_PATH

출력 줄에 추가한 디렉터리가 포함되어 있으면 구성이 올바르게 로드되었으며 동적 로더가 이제 프로그램을 실행할 때 해당 경로를 고려한다는 의미입니다.

기존 기능을 손상시키지 않고 추가 경로를 추가하는 방법

LD_LIBRARY_PATH의 내용을 완전히 바꾸는 것 보다 기존 경로를 유지하면서 다른 경로를 추가하는 것이 더 나은 경우가 있습니다 . 이는 다른 라이브러리가 이미 구성되어 있고 다른 애플리케이션과의 종속성을 깨뜨리고 싶지 않은 경우에 중요합니다.

경로를 "연결"하려면 일반적으로 내보내기 형식이 사용됩니다. 이전 변수 앞에 새 디렉터리를 추가합니다.예를 들어, 추가하고 싶다면 /home/osboxes/sample 이미 정의된 내용에 대해 다음과 같이 작성할 수 있습니다. .bashrc:

export LD_LIBRARY_PATH=/home/osboxes/sample:${LD_LIBRARY_PATH}

순서가 중요한 이유는 동적 로더가 먼저 /home/osboxes/sample에서 검색한 다음 변수가 이미 존재하는 다른 디렉터리에서 검색하기 때문입니다. 이를 통해 특정 테스트에만 우선순위 라이브러리를 포함하고 나머지 구성은 그대로 유지할 수 있습니다.

파일을 수정한 후에는 다시 한번 기억해 두세요. "source" 명령을 실행합니다. 에 ~/.bashrc 현재 터미널에 변경 사항을 적용하고 다시 확인하십시오. echo $LD_LIBRARY_PATH 새로운 경로가 목록의 맨 위에 나타난다는 것입니다.

그것을 추천합니다 LD_LIBRARY_PATH의 지속적인 변경을 피하십시오.잘못된 수정 작업은 예상치 못한 프로그램에 영향을 미칠 수 있습니다. "추가" 패턴을 구문과 함께 사용하십시오. ${LD_LIBRARY_PATH} 일관성을 유지하는 데 도움이 되지만, 과도하게 사용하지 않는 것이 좋습니다.

도서관 검색의 작동 방식과 위험성

LD_LIBRARY_PATH 뒤에는 동적 로더의 매우 특정한 동작 방식이 있습니다. 검색 우선순위이 변수에 입력한 경로는 시스템의 미리 컴파일된 경로 및 표준 디렉터리(예: ...)보다 먼저 처리됩니다. /lib, /usr/lib o /usr/lib64.

문제는 이러한 추가 디렉터리에 시스템 라이브러리와 이름은 같지만 버전이 다르거나 호환되지 않는 라이브러리가 포함되어 있을 때 발생합니다. 동적 로더는 애플리케이션이 원래 다른 버전의 라이브러리에 링크되었더라도 LD_LIBRARY_PATH에서 처음 발견하는 라이브러리를 주저 없이 선택합니다.

이러한 상황은 심각한 보안 문제를 포함하여 여러 유형의 충돌을 야기할 수 있습니다 . 악의적인 사용자가 LD_LIBRARY_PATH를 조작하여 프로그램을 실행하게 만들 경우, 악성 라이브러리가 침투하여 정상적인 버전을 대체하고 원치 않는 코드를 실행할 가능성이 있습니다.

이러한 이유로 setuid 또는 setgid 바이너리는 일반적으로 LD_LIBRARY_PATH를 완전히 무시합니다. 관리자 권한으로 실행되기 때문에 사용자 환경 변수에서 임의의 경로를 허용하는 것은 큰 위험이 될 수 있으므로, 시스템은 이러한 경우 해당 변수를 단순히 무시합니다.

보안 외에도 다음과 같은 측면이 있습니다. 성능과 효율성 주의해야 할 점이 있습니다. LD_LIBRARY_PATH에 디렉터리를 추가할 때마다 로더는 해당 경로에 실제로 존재하지 않는 라이브러리라도 해당 경로의 라이브러리를 열려고 시도합니다. 이로 인해 많은 호출이 실패하게 됩니다. open()"ENOENT(해당 파일 또는 디렉터리가 없습니다)" 오류를 반환하여 애플리케이션 시작 속도를 저하시킵니다.

경로를 추가할수록, 특히 원격 디렉터리(NFS) 인 경우 프로그램 시작 시간이 길어지고 파일 시스템 부하가 커집니다. 수백 명의 사용자가 있는 대규모 환경에서는 LD_LIBRARY_PATH를 과도하게 사용하면 예상치 못한 병목 현상이 발생할 수 있습니다.

일반적인 문제점: 불일치 및 숨겨진 종속성

또 다른 매우 흔한 부작용은 바이너리와 라이브러리 간의 불일치 입니다 . LD_LIBRARY_PATH는 프로그램이 링크된 라이브러리 버전과 다른 버전을 로드하도록 강제할 수 있으며, 이러한 버전은 ABI 또는 동작 수준에서 항상 100% 호환되는 것은 아닙니다.

최악의 경우, 명백한 호환성 문제가 있다면 애플리케이션이 시작되지 않거나 빠르게 충돌하여 문제의 흔적을 남길 것입니다. 하지만 진정으로 위험한 것은 라이브러리가 "어느 정도 작동"하지만, 이후 잘못된 결과를 반환 하거나 디버깅하기 어려울 정도로 미묘하게 다르게 동작하기 시작하는 경우입니다.

특히 문제가 되는 사용 사례 중 하나는 사용자 프로필이나, 더 심각하게는 시스템 프로필에 LD_LIBRARY_PATH를 전역적으로 정의하는 것입니다 . 이렇게 되면 해당 세션에서 실행 중인 모든 애플리케이션이 해당 구성에 노출되는데, 심지어 이러한 추가 경로를 사용하도록 설계되지 않은 애플리케이션까지도 영향을 받습니다.

이러한 전역 경로가 변경되거나 사라지면 많은 바이너리가 갑자기 작동을 멈출 수 있습니다. 아무도 알아채지 못한 사이에 해당 바이너리들이 라이브러리를 찾기 위해 LD_LIBRARY_PATH의 "패치"에 의존하기 시작했기 때문입니다.

이것이 바로 많은 전문 환경에서 변수를 일회성 테스트 도구나 비상 해결책 으로만 사용하고 장기적으로 안정적인 구성 메커니즘으로는 절대 사용하지 않는 데에 그토록 많은 비중을 두는 이유입니다.

실제로 어떤 라이브러리가 사용되고 있는지 확인하는 방법

변경 사항이 LD_LIBRARY_PATH에 어떤 영향을 미치는지 완전히 이해하려면 다음 사항을 아는 것이 중요합니다. 각 실행 파일은 어떤 라이브러리를 사용합니까?여기서는 다음과 같은 명령어를 사용합니다. ldd이는 동적 링크에 대한 상당히 명확한 시각을 제공합니다.

`ldd` 명령어는 주어진 바이너리에 대해 어떤 동적 라이브러리가 필요 하고 어떤 경로에서 로드되는지를 보여줍니다. 예를 들어 다음과 같이 실행하면:

ldd /usr/bin/file

다음과 같은 유형의 줄 목록이 표시됩니다. libmagic.so.1 => /usr/lib64/libmagic.so.1결의안과 함께 linux-vdso.so.1, libc.so.6 그리고 다이내믹 충전기 자체에 대한 정보입니다. 이 정보는 여러분에게 다음과 같은 정보를 제공합니다. 정지 사진 실행 파일의 주요 종속성 중 하나입니다.

하지만 공유 도서관이 필요한 경우도 있습니다. 런타임에 다른 라이브러리를 로드합니다. (예를 들어, 통해 dlopen()이러한 내용은 ldd 명령의 출력에 반영되지 않습니다. 보다 완전한 그림을 보려면 실행 중인 프로세스의 주소 공간에 실제로 매핑된 .so 파일이 무엇인지 살펴보아야 합니다.

일부 Solaris 계열 시스템에서는 프로세스 ID(PID)를 기반으로 프로세스가 로드한 동적 라이브러리 목록을 보여주는 `pldd` 명령어가 있습니다. Bash와 같은 프로그램에서 이 명령어를 사용하면 `ldd` 명령어로 나열된 라이브러리 외에도 문자 변환 모듈이나 사용자 및 그룹 이름 확인을 위한 NSS 모듈 과 같은 다른 라이브러리가 함께 로드되는 것을 확인할 수 있습니다 .

순수 리눅스 환경에서는 pldd가 표준 바이너리 형태로 항상 제공되는 것은 아닙니다. Perl이나 다른 도구로 작성된 스크립트가 있습니다. 정보를 추출하는 것 /proc/<PID>/maps비슷한 효과를 얻을 수 있습니다. 이렇게 하면 LD_LIBRARY_PATH 설정으로 인해 예기치 않은 라이브러리가 로드되는지 확인할 수 있습니다.

LD_LIBRARY_PATH에 의존하지 않는 더 깔끔한 방법

LD_LIBRARY_PATH를 사용한 해결 방법을 여러 개 추가하기 시작할 때 가장 중요한 권장 사항은 간단합니다 . 가능한 한 적게 사용하십시오 . 추가하는 모든 경로는 오류, 버전 충돌 및 성능 문제의 잠재적 원인이 될 수 있으므로 보다 안정적인 대안을 고려하는 것이 좋습니다.

(예를 들어, Linux From Scratch를 따라) 애플리케이션을 컴파일하는 경우 링커의 `-rpath` 옵션을 사용할 수 있습니다 . 이 옵션을 사용하면 실행 파일이 의존하는 라이브러리의 경로를 실행 파일 자체에 직접 포함시킬 수 있으므로, 바이너리는 전역 환경 변수를 수정할 필요 없이 해당 라이브러리를 어디에서 찾아야 하는지 알 수 있습니다.

대표적인 예는 다음과 같습니다.

cc -o myprog obj1.o … objn.o -Wl,-rpath=/path/to/lib -L/path/to/lib -lmylib

이로써 링커는 추가합니다. /path/to/lib를 실행 파일의 실행 경로로 지정합니다.여러 경로가 필요한 경우 환경 변수를 사용하는 것이 매우 편리합니다. LD_RUN_PATH링커도 이를 이해하며, 콜론으로 구분된 디렉터리 목록을 입력하여 채울 수 있습니다.

예를 들어 다음과 같이 할 수 있습니다.

export LD_RUN_PATH=/path/to/lib1:/path/to/lib2:/path/to/lib3
cc -o myprog obj1.o … objn.o -L/path/to/lib1 -lmylib1 -L/path/to/lib2 -lmylib2

컴파일 후에는 다음을 통해 확인할 수 있습니다. ldd 이진수 모든 라이브러리를 올바르게 해결합니다. LD_LIBRARY_PATH에 의존하지 않습니다. "찾을 수 없음" 오류가 발생하는 경우 Makefile과 LD_RUN_PATH 구성을 확인해야 합니다.

재컴파일이 불가능한 경우, chrpath와 같은 도구를 사용하여 실행 파일에 이미 포함된 실행 경로(runpath)를 수정할 수 있습니다. 하지만 이 방법에는 몇 가지 제한 사항이 있습니다. 기존 문자열을 덮어쓰기만 가능하고 확장할 수는 없으며, 실행 파일에 실행 경로가 정의되어 있지 않은 경우에는 변경할 내용이 없습니다.

래퍼 스크립트를 사용하고 명령줄에서 특정 설정을 조정합니다.

-rpath 또는 chrpath를 사용한 링크가 불가능한 경우, 특정 애플리케이션에 대해서만 LD_LIBRARY_PATH를 조정하는 래퍼 스크립트를 사용할 수 있습니다. 이는 사용자 프로필을 수정하는 것보다 훨씬 덜 침해적인 접근 방식입니다.

일반적인 셸 래퍼는 다음과 같습니다.

#! / bin / sh의
LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2:/path/to/lib3
LD_LIBRARY_PATH 내보내기
exec /path/to/bin/myprog «$@»

이 접근 방식을 사용하면 환경 변수는 myprog 프로세스와 그 프로세스가 실행하는 하위 프로세스에만 "영향을 받게" 되며 , 세션에서 실행하는 다른 명령에는 영향을 미치지 않습니다. 특정 애플리케이션에 필요한 특정 라이브러리 버전을 사용해야 하는 경우에 매우 적합한 해결책입니다.

빠른 테스트를 위한 또 다른 매우 유용한 옵션은 `env` 명령어를 사용하여 단일 실행에 대해서만 `LD_LIBRARY_PATH`를 정의하는 것입니다. 예를 들면 다음과 같습니다.

env LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2 ./myprog

이런 식으로 변수가 적용됩니다. 오직 그 기도에만 de myprog그리고 작업이 완료되면 셸은 그대로 유지되며, 다음에 실행하는 명령에 영향을 줄 수 있는 이상한 경로의 흔적도 남지 않습니다.

절대 피해야 할 행동은 다음과 같습니다.

export LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2
./myprog

그 패턴은 LD_LIBRARY_PATH를 남깁니다. 이후의 모든 주문에 대해 정의됨 해당 터미널에서 실행하는 명령은 나중에 추적하기 매우 어려운 부작용을 일으킬 수 있습니다. 개별 테스트의 경우, 호출은 다음과 같습니다. env 훨씬 깨끗해요.

피해야 할 좋은 관행과 일반적인 실수

널리 받아들여지는 황금 권장 사항은 다음과 같습니다. 로그인 프로필에서 LD_LIBRARY_PATH를 절대 정의하지 마십시오.사용자 파일이나 시스템 파일에 추가하지 마십시오. 다시 말해, 다음과 같은 파일에 추가하지 마십시오. ~/.bash_profile, ~/.profile, /etc/profile 또는 유사합니다.

이처럼 민감한 변수를 전역적으로 설정하면 해당 사용자가 실행하는 모든 애플리케이션이 시스템 라이브러리와 완벽하게 호환되도록 구성된 애플리케이션까지 포함하여 해당 추가 경로를 사용하게 됩니다. 따라서 특정 스크립트 또는 일회성 실행 으로 범위를 제한하는 것이 훨씬 안전한 접근 방식입니다.

또한 설치 과정에서 LD_LIBRARY_PATH를 프로필에 추가하도록 요청하거나 자동으로 전역적으로 추가하는 타사 설치 프로그램은 주의해야 합니다 . 대부분의 경우 이는 제공업체에게는 간편한 방법이지만, 장기적으로 사용자 환경에 문제를 일으킬 수 있습니다.

가능하면 조금 더 노력해서 깔끔한 대안을 찾는 것이 좋습니다 . 실행 파일의 실행 경로를 조정하거나, 라이브러리를 표준 디렉터리에 설치하거나, ​​최신 패키징 메커니즘을 사용하거나, 일반적인 환경 변수를 건드리는 대신 스크립트 래퍼로 앱을 감싸는 방법 등이 있습니다.

변수를 사용해야 하는 경우 경로를 최대한 간결하고 구체적으로 유지하고 , 디렉터리 수를 최소화하며, 꼭 필요한 경우가 아니면 원격 파일 시스템에 있는 경로는 절대 사용하지 마십시오.

이러한 모든 점을 고려할 때, LD_LIBRARY_PATH는 강력하지만 조심해야 하는 도구 입니다 . 새로운 라이브러리 버전을 테스트하거나, 오래된 .so 파일의 위치를 ​​변경하거나, 대규모 애플리케이션을 위한 독립 실행형 환경을 구축하는 데 매우 유용하지만, 무분별한 사용은 보안 위험, 성능 문제, 그리고 디버깅하기 어려운 불일치를 초래할 수 있습니다. 동적 로더의 작동 방식을 이해하고, -rpath, LD_RUN_PATH 또는 래퍼 스크립트와 같은 대안을 활용하며, 이 변수를 매우 특정한 컨텍스트로 제한하는 것이 LD_LIBRARY_PATH를 시스템에 함정이 되지 않도록 활용하는 가장 좋은 방법입니다.