중복 가능성:
공유 라이브러리가 실행 가능한 이유는 무엇입니까?
Linux에서 .so
파일 권한이 /lib
644가 아닌 755인 이유는 무엇입니까? 이거 이상해 보여
~에 따르면http://www.gossamer-threads.com/lists/gentoo/user/231943, 이는 오래된 glibc의 것 같습니다. 내 임베디드 시스템 /lib/libc.so.6에서는 권한 644에서도 작동합니다.
답변1
나는 이것이 단지 역사적인 이유 때문일 것이라고 생각합니다.
BlueBomber의 답변은 역사적으로 정확할 수도 있지만 실제로는 그렇지 않습니다.필요한공유 객체를 실행 가능하게 만듭니다.
내 우분투 시스템에서는 그렇지 않습니다. 30개와 /lib/*.so*
600개의 파일 중 /usr/lib/*.so*
단 하나만 실행 권한을 갖고 있습니다. 이것은 아마도 단순한 결함일 것입니다.
실행 권한을 사용하면 파일이 해당 기능 중 하나를 통해 실행될 수 있습니다 exec*()
. 공유 객체 파일에는 실행 가능한 코드가 포함되어 있지만 그런 방식으로 실행되지는 않습니다.
반면에 내가 액세스할 수 있는 CentOS 5.7 시스템에서는 이 파일이예실행 파일. SPARC Solaris 9 시스템에도 있습니다. (이러한 파일 중 일부에 대한 실행 권한을 꺼서 문제가 있는지 확인하는 것이 흥미로울 수 있지만 그렇게 할 수는 없습니다.)
(어떤 Linux 배포판을 사용하고 있습니까?)
고쳐 쓰다:
이 답변도착하다이 문제실제로 실행 비트가 필요한 시스템(HP-UX)의 예를 보여줍니다. 일부 배포판에는 실행 비트 세트(아마도 역사적 관성으로 인해)가 있고 다른 배포판에는 그렇지 않은 Linux에서는 그렇지 않은 것 같습니다. 아니면 일부 Linux에서는 이를 요구할 수도 있습니다.
또 다른 데이터 포인트: 내 Ubuntu 시스템에서 나만의 공유 개체 파일을 만들어 보았습니다. 결과 "libfoo.so" 파일은 실행 권한으로 생성되지만 수동으로 수행하면 chmod -x
이를 사용하는 프로그램이 계속 작동합니다.
그럼에도 불구하고, *.so
파일에 대한 실행 권한을 설정하는 것은 기본적으로 무해합니다(그리고 확실히 소스 파일에 대한 실행 권한을 설정하는 것보다 덜 짜증스럽습니다).
업데이트 2:
fwyzard가 의견에서 지적했듯이 일부 *.so
파일은 실제로 실행 가능합니다. 예를 들어 현재 시스템에서 이 명령을 실행하면 /lib/x86_64-linux-gnu/libc-2.27.so
GNU C 라이브러리의 버전 정보가 인쇄됩니다. /lib/x86_64-linux-gnu/libpthread-2.27.so
행동도 비슷합니다.
답변2
귀하의 질문을 이해한다면 공유 객체 파일에 실행 권한이 있는 이유를 묻는 것입니다. 이는 링크할 라이브러리 파일이고 포함된 코드가 실행되기 때문입니다.
인용하다: