PATH 변수에 LaTeX를 추가했는데 쉘 구성을 여러 컴퓨터에 전송하면 모든 컴퓨터에 LaTeX가 설치되어 있지 않습니다. 소프트웨어에 액세스할 수 없다는 명백한 결과 외에도 PATH 변수가 참조하는 소프트웨어가 시스템에 존재하지 않을 때 PATH 변수를 구성하면 다른 부정적인 영향이 있습니까?
내 .zshenv 파일:
# TeX Live
export PATH=$PATH:/usr/local/texlive/2023/bin/x86_64-linux
답변1
전혀. 쉘은 이 위치를 열려고 시도하는 데 약 0.00005초를 소비하며 실패하고 계속합니다.
이 위치가 액세스할 수 없는 원격 파일 시스템에 있는 경우 실제 가능한 유일한 문제가 발생할 수 있습니다. 이로 인해 명령을 자동 완성하려고 할 때마다 1분씩 긴 지연이 발생할 수 있습니다.
답변2
이는 잠재적인 부정적인 영향을 미칠 수 있지만 실제로는 중요하지 않습니다.
추가된 디렉터리에 있는 소프트웨어에 의존하지만 설치되지 않은 명령을 실행하려고 할 때마다 해당 명령이나 실행 파일을 찾을 수 없다는 오류 메시지가 나타날 수 있습니다.
시스템의 기존 명령과 충돌하는 명령 또는 실행 파일 이름이 포함된 디렉터리를 추가하면 예기치 않은 동작이 발생할 수 있습니다.
쉘이 명령을 발견하면 변수에 나열된 디렉토리에서 명령을 검색합니다
PATH
. 참조하는 소프트웨어가 설치되어 있지 않으면 쉘은PATH
명령을 사용할 수 없다고 결정하기 전에 모든 디렉토리를 검색해야 합니다. 이러한 추가 검색 시간으로 인해 명령 실행이 약간 지연될 수 있습니다.
if
내보내기를 수행하기 전에 소프트웨어가 존재하는지 확인하는 명령문을 추가할 수 있습니다 .
셸 구성을 여러 컴퓨터로 전송하려는 경우 각 컴퓨터에 대해 별도의 구성 파일을 생성하고 PATH
각 시스템에서 사용 가능한 소프트웨어에 따라 변수를 적절하게 사용자 정의하는 것을 고려할 수 있습니다.
또는 필요한 소프트웨어나 디렉터리가 있는지 확인하기 위해 셸 구성에 추가 검사를 포함시킵니다.
답변3
디렉터리를 추가하면 $PATH
프로그램 실행 프로세스에 오버헤드가 추가됩니다. 쉘은 이를 최적화하려고 시도하지만 쉘 외부에서도 오버헤드는 일반적으로 사소한 것이며, 특히 존재하지 않는 디렉토리의 경우 더욱 그렇습니다.
동일한 디렉터리를 여러 번 추가하는 것은(예제에서 잠재적으로 그렇듯이) 추악하지만 일반적으로 성능 측면에서는 여전히 사소한 일입니다.
신뢰할 수 없는 디렉터리를 경로에 추가하면 보안에 영향을 미칠 수 있지만 이 경우에는 신뢰할 수 없는 디렉터리가 아니라 존재하지 않는 디렉터리이고 잠재적인 상위 디렉터리는 루트가 소유해야 하기 때문에 해당 사항이 적용되지 않는다고 생각합니다.
최악의 결과는 디렉터리가 위치한 디스크가 실패한 디스크에 있게 되는 것입니다(예: NFS 마운트 지점이 응답하지 않는 서버를 가리킴). 그러나 이는 일반적인 경우는 아닙니다. (결과가 매우 느리거나 로그인 실패가 발생할 수 있습니다.)
답변4
경로의 위치에 따라 일반 사용자가 해당 경로와 일치하는 디렉터리/파일을 만들 수 있는 경우 보안 문제가 발생할 수 있습니다.
경로의 시작 부분 근처에 있는 경우 충분한 권한이 있는 사람이 해당 경로와 일치하는 디렉터리를 만들 수 있으며 해당 디렉터리의 실행 파일은 ls
이전에 Script to라고 불리는 것과 같이 일반적으로 신뢰할 수 있는 실행 파일의 이름을 딴 스크립트를 배치할 수 있습니다. 실제 ls
.
일반적으로 이 공격은 명령을 입력하게 되는 다른 사용자 간의 정보를 수집하기 위해 수행됩니다. 위조자는 ls
사용자 정보를 획득하고, 해당 사용자로서 명령을 실행하고, 심지어 해당 정보를 시스템 외부로 보낼 수도 있습니다. 일반적으로 이러한 스크립트는 실제 스크립트를 실행 ls
하고 응답을 콘솔로 다시 파이프하여 차단 검색을 지연시킵니다.