`/ usr / local`을 숨기는 것이 안전한가요?

/usr/local로컬 컴퓨터 용 소프트웨어를 설치 하는 것이 무엇인지 알고 있습니다. 기본적으로 root디렉토리를 소유합니다. 즉, 설치하려면를 사용해야 sudo합니다. 단일 사용자 또는 개발자 시스템의 경우 이는 불필요한 추가 명령 사용과 같습니다. 따라서 내 질문은-내가 소유하는 것이 안전 /usr/local합니까?

예를 들어, Homebrew for OS X "Just Works"는를 사용하지 않고 소프트웨어 를 소유 /usr/local하고 안전하게 설치 하기 때문 입니다 sudo.

또한 로컬에 컴파일 된 소프트웨어를에 설치 한 경우 /usr/local현재 소프트웨어를 수정하거나 플러그인을 설치하려면 루트가 필요합니다. 이것은 안전하지 않은 것 같습니다 . 정확히 무슨 일이 일어날 지 sudo알고 싶을 때만 사용하고 싶습니다 .

의견?

나는 소유자가되는 것을 추천 할 수 없다 /usr/local; 대부분의 경우을 사용하는 것보다 안전하지 않을 수 sudo있습니다.

귀하의 질문은 당신이 원하는 두 가지 이유를 제안합니다 chown /usr/local.

첫 번째는 sudo소프트웨어를 설치 하는 데 사용하지 않는 것 입니다. 이것은 효율적으로 일하고 싶다고 말하거나 암호 를 입력 하고 입력하는 데 필요한 키 입력을 저장한다고 말하는 사람 ( 이 답변 작성자와 같은)에게 읽을 sudo수 있습니다. 그러나 아마도 "불필요하다"고 말할 때 가장 작은 특권 의 원칙을 말하는 것입니다 .

기본적으로 root디렉토리를 소유합니다. 즉, 설치하려면를 사용해야 sudo합니다. 단일 사용자 또는 개발자 컴퓨터의 경우 불필요한 추가 명령 사용처럼 보입니다.

나는 "이 시스템을 사용하는 유일한 사람이므로 sudo암호 를 사용 하거나 입력 할 필요가 없습니다 ."라는 문구에 따라 의견을 듣고 / 들어오는 사람들을 자주 읽거나 읽습니다 . 그러한 견해를 가진 독자들에게 그리고 여기에 관련이 있기 때문에 근본적인 이유가 무엇인지를 상기시켜 봅시다.

Ubuntu 시스템에 설치된 대부분의 프로그램 파일은 파일 모드 755 또는 기호 표기법을 사용합니다 rwxr-xr-x. 즉, 모든 사용자 나 프로그램 이 파일을 실행할 수 있지만 파일 소유자 인 root 만 수정할 수 있습니다. (기술적으로 이것은 루트 w이외의 다른 사람이 자신을 포함하는 디렉토리에 대한 권한을 가지고 있지 않기 때문에 다른 사용자가 삭제하거나 이동할 수 없습니다.)

즉, 겸손한 사용자는 모든 프로그램을 실행할 수 있습니다. 루트가 소유 한 파일에 대해 쓰기 작업을 수행하는 등 권한이없는 작업을 수행하기 위해 프로그램을 사용하려고하면 오류가 발생합니다. 이로 인해 일부 명령, 버그가 많은 응용 프로그램 또는 악성 코드에 오타가 발생하여 시스템을 엉망으로 만들 가능성이 줄어 듭니다. 루트로 실행되지 않으면 그렇게 할 수있는 권한이 없습니다. 인터넷과 상호 작용하는 프로그램을 실행할 때 특히 유용합니다.

당신이 경우 chown /usr/local, 어떤 프로그램은 나중에 같은 동일한 이름의 다른 명령을 대체하는 등에 의해, 어떤 이유로 루트로 실행 얻을 수있는이 파일을 쓸 수있는 사용자의 권한으로 실행. /usr/local/bin기본에 $PATH, 그리고에서 sudo의 ' secure_path, 그리고 그것을 제공 하기 전에 모두 다른 위치. 두 개의 실행 파일이 있다면

/usr/local/bin/chown
/bin/chown

내가 실행할 때 sudo chown ..., 에서가 실행됩니다 .chown/usr/local/bin

그러나 두 번째 이유는 보안에 관한 것이므로 이미 모든 것을 알고 있었을 것입니다.

또한 로컬에 컴파일 된 소프트웨어를에 설치 한 경우 /usr/local현재 소프트웨어를 수정하거나 플러그인을 설치하려면 루트가 필요합니다. 이것은 안전하지 않은 것 같습니다 . 정확히 무슨 일이 일어날 지 sudo알고 싶을 때만 사용하고 싶습니다 .

_{이런 경우에 그것이 로컬로 컴파일 된 소프트웨어를 설치하는 데 절대적으로 오른쪽 (어쨌든 FHS에 따라)이다, 여기를 언급하는 것이 필요 /usr/local하지만, 그 자체를 컴파일하면에서 수행 어딘가에해야 $HOME하지 않고, sudo사용자가 입력하는 마지막 단계까지, sudo make install또는 이에 상응하는.}

/usr/local권한이없는 소유자로 설치된 프로그램을 실행하면 자신을 업데이트하려고 할 때 발생하는 특정 권한 오류를 사용하여 자신이 소유하지 않은 다른 파일 시스템 위치를 수정하려고한다는 것을 알 수 있다고 생각합니다 원하지 않기 때문에 그렇게하지 못하게 할 수 있습니다.

도움 이 될 수 있습니다. 그 의미는 프로그램이 프로그램 내 /usr/local에서 좋아하는 것을 수행 하지만 다른 곳에서는 수행하지 않는다는 것을 신뢰한다는 것 입니다. 높은 권한을 요청하면 업데이트 또는 제거를 거부 할 수 있습니다. 그것은 나에게 의미가 있습니다. 그러나 /usr/local이런 방식으로 일종의 샌드 박스 로 사용하려고 시도하는 것은 좋은 생각이 아니거나 적어도 가장 안전한 솔루션이 아닐 것입니다. 제대로 격리 된 위치 /opt가 아닙니다 (기본값이 아니기 때문에 조금 더 격리되어 있습니다 $PATH). 프로그램이 무언가를 쓰거나 삭제 /usr/local하여 해를 입힐 수 있습니다. 당신이 실행하는 다른 (잠재적으로 잘못 작성된) 프로그램은 당신이 모르는 코드를 작성하고 실행할 수 있습니다.

프로그램이 안전하게 업데이트되도록하는 것이 걱정된다면 대안을 찾아야합니다 (예를 들어, 파이썬과 같이 프로그램에 특정하거나 필요에 맞는 스냅 또는 유사한 구현을 찾거나 사용할 수 있음) 일반 사용자가 실행하는 프로그램에 의해 시스템 위치 (상대적으로 사용자가 포함 된 위치)가 노출되기 전에 잠재적으로 안전하지 않은 소프트웨어를 테스트하기위한 컨테이너 또는 VM. 프로그램에 일시적으로 권한을 상승 시켜서 예측할 수없는 효과가있는 것 같습니다 sudo.

이 /usr/local소유하지 않은 것은 드문 일입니다 root. 그러나 원하는대로 소유자를 변경할 수 있습니다.

그러나 보안 문제를 피하기 위해 /usr/local/sbin여전히 소유하고 있는지 확인하는 것이 root좋습니다. 여기의 명령은 일반적으로 루트 만 호출합니다.

소프트웨어의 경우에만 당신이 필요 대신 홈 디렉토리를 사용합니다 /usr/local.

/usr/local원하지 않는 경우 명령 소유권을 변경 하거나 루트로 명령을 실행 하는 대신 빌드가 대신 홈 디렉토리에 설치되도록 구성해야합니다 /usr/local. 이것은 디렉토리 와 서브 디렉토리 의 경로를 /usr/local포함하여 의 소유권 변경과 관련된 모든 잠재적 인 문제를 해결 합니다.binsbinroot

다른 사용자가 소프트웨어를 실행하도록 허용해야하는 경우 액세스 권한을 부여 할 수 있습니다. 사실, 기본적으로 홈 디렉토리에는 읽기 및 실행 액세스 권한 이 있기 때문에 아마도 이미 가능할 것입니다 . (필요하지 않은 경우 chmod비공개로 만들려는 파일이나 디렉토리를 사용하고을 변경하여 쉽게 변경할 수 있습니다 umask.)

홈 디렉토리에 소프트웨어가 설치되어 있으면 바이너리 /usr/local/bin가 대신 들어갑니다 . 설치 한 소프트웨어 의 서브 디렉토리에 해당하는 홈 디렉토리의 다른 서브 디렉토리 가 제공됩니다. 일반적으로 소스 코드에서 소프트웨어를 설치할 때 자동으로 발생합니다./home/username/bin/usr/local

빌드 구성

소스 코드에서 빌드하는 대부분의 소프트웨어에는 다음 단계가 실행됩니다.

./configure

configure이와 같이 실행될 수 있는 스크립트 와 함께 제공되는 대부분의 소프트웨어는 기본적으로 설치를 위해 /usr/local실행할 때 설치를위한 빌드 구성으로 기본 설정 sudo make install됩니다. 그 이유는 다음과 같이 암시 적으로 실행하기 때문입니다.

./configure --prefix=/usr/local

홈 디렉토리에 설치할 빌드를 구성하려면 다음을 대신 사용하십시오.

./configure --prefix="$HOME"

실제로 우분투에서 홈 디렉토리 경로에는 공백, 다른 공백 또는 쉘과 같이 특수하게 처리되는 다른 문자가 포함 *되어 있지 않으므로 사용자 계정을 매우 이상하게 설정하지 않으면 다음 과 같이 입력하면됩니다.

./configure --prefix=$HOME

( 하지만 스크립트 작성을 습관화하는 것은 좋지 않습니다 . 또한 macOS와 같은 일부 다른 OS에서는 사용자의 홈 디렉토리 경로에 공백이 포함되는 경우가 드물지 않습니다.)

또는 원하는 경우 전체 홈 디렉토리 경로를 입력 할 수 있습니다.

./configure --prefix=/home/username

( username물론 실제 사용자 이름으로 바꾸십시오. 어떤 이유로 홈 디렉토리가 없으면 /home그에 따라 조정해야합니다.)

빌드 설치

을 실행 한 후에 make는 running에 익숙 할 수 sudo make install있지만, 자신의 홈 디렉토리에 설치할 때 루트로 실행할 필요가 없으므로 루트 를 생략 할 수 있습니다 sudo. 그냥 실행 :

make install

마찬가지로 uninstall대상 을 지원하는 소프트웨어의 경우 :

make uninstall

이것은 정확히 당신이 요구 한 것입니다 ... 홈 디렉토리가 아닌 /usr/local.

프로그램 실행

아마도bin 홈 디렉토리 의 서브 디렉토리는 다음 중 하나입니다.

• 이미 귀하 $PATH의 또는
• 당신에있을 것입니다 $PATH방금 로그 아웃 한 후 다시 로그인합니다.

그 이유는 .profile로그인 할 때 실행되는 명령이 들어있는 홈 디렉토리 의 파일에 대부분 의 우분투 버전 에서 생성 된 사용자 계정 (OS를 설치할 때 생성 된 초기 관리자 계정 포함) 에 대해 기본적으로이 파일이 포함되어 있기 때문입니다 .

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

해당 코드는 로그인 할 때 실행되므로 (로그인했기 때문에 .profile) 개인 bin디렉토리 $PATH 가 해당 시점에만 존재합니다. 따라서 로그 아웃했다가 다시 로그인해야 할 수도 있습니다.

Ubuntu 14.04와 같은 이전 릴리스 와 Ubuntu 17.10과 같은 최신 릴리스 가 함께 제공됩니다. 그러나이 글을 쓰는 시점에서 가장 인기있는 Ubuntu 16.04는 다음과 같습니다.

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

즉 단순히 추가 bin홈 디렉토리의 하위 디렉토리 ---뿐만 아니라 .local/bin하위 디렉토리를 - 당신에게 $PATH, 그 디렉토리가 실제로 존재하는지 확인하지 않고. 따라서 16.04를 사용하거나 사용자 계정을 만들 때 16.04 인 시스템 에서 업그레이드 한 경우 bin홈 디렉토리 의 하위 디렉토리는 이미에 있습니다 $PATH.

귀하의 .profile파일이 복사되는 /etc/skel사용자 계정을 만들 때 디렉토리. 이전 Ubuntu 릴리스에서 사용자 계정을 만든 경우 해당 버전의을 (를) 얻었으며 .profile사용자 계정에 대해 최신 릴리스로 업그레이드하여 변경되지 않았습니다.

bin홈 디렉토리 의 하위 디렉토리가에 있으면 $PATH우분투 패키지 관리자가 설치하거나 내부에 설치된 프로그램과 마찬가지로 이름을 입력하여 실행 파일이 설치된 프로그램을 실행할 수 있습니다 /usr/local.

.local옵션

.profile위에서 설명한 16.04를 포함하여 일부 Ubuntu 릴리스에서 생성 된 사용자 계정 의 기본 파일이 $HOME/bin경로뿐만 아니라에 추가됨 을 알 수 있습니다 $HOME/.local/bin. 당신이 경우 .profile그 추가하지 않습니다,하지만 당신이 원하는 , 그것은에 당신은 단순히 편집이 가능합니다.

설정 및 캐시 된 데이터를 저장하는 데 자주 사용 되지만 .local홈 디렉토리 의 하위 디렉토리에 소프트웨어를 설치할 수도 있습니다 . 사용성 및 보안 관점에서 --prefix="$HOME/.local"와 비슷 하므로 사용에 방해가되지 않아야 합니다 --prefix="$HOME".

로 시작하는 파일과 디렉토리 .는 그래픽 파일 브라우저 (기본적으로 Ctrl+ H를 사용 하여 숨기기 해제 및 다시 표시) 또는 ls명령 ( -A또는 -a플래그를 전달하여 표시)에 표시되지 않습니다. 이것은 원하는 것이 아니거나 정확히 원하는 것일 수 있습니다. 이것은 개인적인 취향의 문제입니다.

그러나 홈 디렉토리에 소프트웨어를 빌드하고 설치하는 일부 자동화 된 소스 기반 패키지 관리자가 사용되는 것으로 나타났습니다 $HOME/.local. 실제로 이것이 얼마나 일반적인지 알지 못합니다. 더 자세히 조사 하고이 답변을 업데이트하기를 희망하지만 $HOME수동으로 컴파일하는 작업 에만 사용 하는 것이 좋습니다. 그렇게하면 어디에서 왔는지 분명해질 것입니다. 충돌이 발생해도 소프트웨어는 여전히 공존 할 가능성이 높습니다.

에서 일부 소프트웨어 $HOME/.local와 다른 소프트웨어를 일부러 설치할 수도 있습니다 $HOME. 그것은 당신에게 달려 있습니다. 어느 bin디렉토리 처음에 나타납니다 $PATH명령이시에서 실행하는 일을 환경 변수입니다 모두에서 같은 이름의 존재의 명령.

신용이가는 ZANNA 및 Videonauth 에 대한 오류를 지적 A의 이전 버전의 우분투 출시에있는 기본 코드를 가지고있는 대한이 답변 .profile하고 해결하는 저를 도와 해야합니다 (참조 여기에 ).

sudo가 불편한 경우 / do / sudoers를 업데이트하면 sudo를 실행할 때 비밀번호를 입력 할 필요가 없습니다. 나는 이것이 / usr / local의 소유자를 변경하는 것보다 더 나은 해결책이라고 생각합니다.