LD_LIBRARY_PATH을 사용하여 응용 프로그램에 대한 특정 사용자 라이브러리의 경로를 설정합니다. 나는이 응용 프로그램에 기능을 설정한다면리눅스 기능 (setcap)은 LD_LIBRARY_PATH를 비활성화하는 것으로 보입니다.
sudo setcap CAP_NET_BIND_SERVICE=eip myapplication
는 LD_LIBRARY_PATH는 무시 될 것으로 보인다. 프로그램을 시작하면, 리눅스는 특정 공유 라이브러리를 찾을 수 없다는 불평을합니다.
확장 된 권한을 가진 응용 프로그램이 도용되는 것을 막기 위해 어떤 종류의 보호 기능이 제공되는 것 같습니다. 해결 방법이 있습니까?
예, 보안상의 이유로 사용 중지되었습니다. sudo위한
man page 설명 : 대부분의 운영 시스템에서 동적 링커 sudo를 포함 setuid를 실행의 환경에서 동적 링크를 제어 할 수 변수를 제거
참고있다. 운영 체제 에 따라이 RLD을 포함 할 수있다 *, DYLD * LD_ , LDR_, LIBPATH, SHLIB_PATH, 그리고 다른 사람. 이러한 유형의 변수는 sudo가 실행을 시작하기 전에 환경 에서 제거되므로 sudo가이를 유지할 수 없습니다.
this link explains이 메커니즘은 실제로 glibc에 있습니다. UID가 EUID와 일치하지 않으면 (프로그램의 경우, sudo 포함), 모든 "안전하지 않은 환경 변수"가 제거됩니다. 따라서 상승 된 권한을 가진 프로그램이 변경없이 실행됩니다.
이 모든 것이 매우 좋지만 setcap은 UID 또는 EUID를 변경하지 않습니다. 권한 ("권한 상승")을 추가합니다. – reinierpost
이미 다른 답변에서 설명한 것처럼이 동작은 의도 된 것입니다. 응용 프로그램을 직접 컴파일 (또는 최소한 링크) 할 수 있다면 몇 가지 해결 방법이 있습니다. 그런 다음 -Wl,-rpath <yourDynamicLibraryPath>을 gcc 또는 -rpath <yourDynamicLibraryPath>을 ld에 전달할 수 있으며 실행시에는 LD_LIBRARY_PATH을 지정할 필요가 없습니다.
어떤 편집기를 사용하여이 파일을 열 xyz.conf 새 파일 $ 터치를 만들 디렉토리 $cd /etc/ld.so.conf.d/ 로 이동 $vi xyz.conf
추가 : 다음과 같이
감사합니다, 그것은 매력처럼 작동합니다. –
리눅스에서이 문제에 대한 해결책은 예를 들어 라인별로이 파일에서 동적 라이브러리 경로다음과 같이 경로 인 경우 다음과 같이
는/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ 다음이 파일의 세 가지 항목이 있어야합니다 : /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/
그런 다음이 파일을 저장하고 다음 명령을 실행 : $ldconfig
위에서 언급 한 모든 작업은 루트 로그인에서 수행해야합니다.
고려해야 할 대안은 rpath를 설정하기 위해 patchelf를 사용하여 잘못 컴파일 된 ELF 공유 라이브러리 및/또는 실행 파일을 "수정"하는 것입니다. https://nixos.org/patchelf.html
ld.so.conf가 항상 확실한 것은 아닙니다. 실행중인 모든 것이 제대로 컴파일 된 경우 작동합니다. 필자의 경우 특수하게 패키지화 된 특정 공급 업체의 아파치 제품을 사용하면 너무 작게 컴파일되었습니다. 고유 한 .so 파일 이름을 사용하지 않아서 공통적으로 사용되는 라이브러리를 제공하는 기본 RHEL 저장소의 RPM 파일 이름과 충돌합니다. . 따라서 이것이 사용 된 방법을 격리하는 유일한 방법이었습니다. 공급 업체의 lib 경로에있는 공유 객체에 대해 ld.so.conf를 사용하면 시스템 전체에서 glibc 공유 라이브러리 오류와 함께 yum을 포함하는 많은 것을 날려 버렸을 것입니다.
https://bugzilla.redhat.com/show_bug.cgi?id=448594 – mpe