추가 읽기

추가 읽기

centos(그리고 다른 많은 배포판도 있다고 생각합니다)에서 모든 사용자의 vi 별칭은 기본적으로 vim입니다. 그러나 어떤 이유로든 vi에는 루트 사용자에 대한 vim이라는 별칭이 없습니다. sudo를 사용할 때 vi 대신 vim을 입력하는 것을 잊고 당연하게 여기는 vim 기능이 없으면 항상 짜증이 납니다. 예를 들어, 기본 구문 강조.

앨리어싱이 수행되는 방식과 sudo/su를 수행할 때 별칭이 존재하지 않는 이유를 프로그래밍 방식으로 이해합니다. 이 동작이 바람직한 이유가 있는지 묻고 있습니다. 즉 왜 centos 개발자가 루트에 대한 별칭을 추가하지 않습니까? 루트 사용자의 vim 별칭에는 일반 사용자에게는 존재하지 않는 일종의 보안 또는 기능 문제가 있습니까? 루트에 이 별칭이 있으면 안되는 역사적 이유가 있나요?

그 외에도 내가 유지 관리하는 서버의 루트 사용자에 대해 vim에 기본 vi 별칭을 추가하면 어떤 해가 있습니까? 이렇게 하려면 더 좋은 방법을 사용해야 할까요(아니면 어떤 방법을 써야 할까요)피하다보안상의 이유로 사용됩니까? )

답변1

그러한 결정은 종종 다음에 대한 우려에 달려 있습니다.유지 관리가 용이함그리고안전, 보안은 다른 답변에서 언급한 요소이지만. 일부 시스템 관리자는 수퍼유저의 대화형 환경에 대한 이상하고 문서화되지 않은 개인 사용자 정의를 원하지 않습니다. 그들은 일이 표준적이고 문서화된 방식으로 실행되기를 원합니다. 게다가 그들은 피하고 싶어한다.재신청신규 설치, 시스템 업그레이드 등 개인 맞춤화

의 경우 잠재적인 vi이름으로 별칭을 지정합니다.vim다른 프로그램 불러오기/usr/bin/vim대신 CentOS에서는 /bin/vi전자가 존재하고 다양한 기능이 컴파일된 선택적 "향상된 VIM"인 반면, 후자는 거의 선택적 기능을 활성화하지 않는 "마이크로 VIM"입니다. (Ubuntu에도 비슷한 아이디어가 있습니다.) 일반적으로 이 vi명령이 표준 vi명령처럼 작동할 것으로 예상합니다.특히슈퍼유저로 작업할 때. 그들은 놀라운 방식으로 상황을 변화시키는 향상된 마법 기능이나 추가 기능을 원하지 않으며, 더 나쁜 경우에는 구조 모드나 비상 모드로 전환됩니다. 그들은 vi슈퍼 유저로서 중요한 작업을 수행하는 누군가가 참조한 모든 참조 문서가 이와 같은 이유로 끔찍하게 잘못되는 것을 원하지 않습니다 .

즉, 요청할 때가 아닌 vi관리자가 요청할 때 호출됩니다 .vivim

즉, 주어진사람들은 이미 다양한 VIM 사용자 정의 및 확장을 당연하게 여기고 있지만 실제로 슈퍼유저 계정을 당연하게 여기는 경향이 있습니다.아니요이러한 사용자 정의 및 확장이 있습니다. 그들은 이 가정을 World Wide Web의 페이지, Q&A에 대한 답변, 자신이 쓴 책에 통합합니다. 그들은 습관을 형성하고 한 시스템에서 다음 시스템으로 지식을 전달하며, 슈퍼유저가 실행되면 원하는 것을 얻습니다 vi. (가끔 이아이러니하게도 VIMism이 있습니다. Linux 운영 체제에서 FreeBSD로 전환할 때 사람들이 배워야 할 한 가지는 viVIM이 아닌 nvi입니다. )

또한 시스템 전체 구성 파일 외에도 /root/.vimrc하드 드라이브 변경, 시스템 재설치 등을 기억할 필요가 없습니다 ./root/.gvimrc

이 아이디어가 실제로 적용된 또 다른 예는 toorFreeBSD의 계정입니다. 수퍼유저이지만 Bourne과 같은 쉘(실제로는 Almquist 쉘)을 사용합니다. 계정 root에 TENEX C 쉘이 있고수십 년-C 쉘 드라이버 시스템의 슈퍼유저 사용을 보여주는 BSD doco의 가치는 그대로 두고 toorBourne과 같은 상호 작용에 사용하라는 조언이었습니다. C 셸은 로 로그인할 때 예상되는 환경이며 root, FreeBSD 관리를 위한 C 셸 매뉴얼을 가지고 있는 수퍼유저에게 Bourne과 같은 셸을 제공한다면 재미있고 잠재적인 재앙이 발생할 수도 있습니다.

추가 읽기

답변2

이 질문은 개인적인 의견을 묻는 질문입니다. 관리자는 자신에게 맞는 방식으로 시스템을 설정할 수 있으며, 기본값이 귀찮다면 변경하는 것이 좋습니다.

하지만...

루트 사용자는 일반 사용자가 아니므로 루트로 로그인한 동안 대화형 프롬프트에서 수행하는 모든 작업을 주의 깊게 고려하는 것이 가장 좋습니다. 관리자에게 루트로 로그인했음을 알리기 위해 대부분의 셸의 루트 프롬프트는 기본적으로 권한이 있는 사용자의 기본 프롬프트와 다릅니다. 매우 길다(있는 경우) 1 .

한 가지 이유 vi는 별칭이 없다는 것입니다.vim 가능한공유 라이브러리가 AWOL(디스크 오류 또는 우발적인 삭제로 인해)되는 경우 vi어쨌든 작동하는 정적 실행 파일이 있을 수 있고(또는 다른 경로의 라이브러리와 연결될 수 있음) 관리자가 다음을 수행할 수 있다고 생각합니다. 시스템의 나머지 부분을 다시 시작하고 실행하려면 파일을 편집하십시오.

일반 사용자가 좋아할 만한 다른 "종소리와 휘파람"에도 동일한 추론이 적용됩니다. 관리자가 대화형 루트 셸을 실행해야 하는 상황에서는 추가 기능에 대한 종속성을 전혀 사용하지 못할 수 있습니다.


1루트 프롬프트에서 작업하면 입력한 명령에 대한 감사 추적이 없습니다. 따라서 누가 무엇을 언제 수행하는지 기본적으로 기록되므로 sudo루트 관련 작업 수행과 같은 도구를 사용하는 것이 좋습니다 . sudo이는 여러 사람이 관리자 권한을 갖고 있는 시스템 및 회사 시스템에 특히 중요합니다.

답변3

이 동작이 바람직한 이유가 있는지 묻고 있습니다. 즉 왜 centos 개발자가 루트에 대한 별칭을 추가하지 않습니까? 루트 사용자의 vim 별칭에는 일반 사용자에게는 존재하지 않는 일종의 보안 또는 기능 문제가 있습니까? 루트에 이 별칭이 있으면 안되는 역사적 이유가 있나요?

루트 대 사용자를 확인하면 echo $PATH더 짧은 목록이 표시됩니다.기본적으로

그것은 기본적으로 보안입니다심리학하나를 위해기본즉시 사용 가능한 Linux 보안 상태...설치하고 모든 설정을 원하는 사용자를 위한 제품안전.

그 외에도 내가 유지 관리하는 서버의 루트 사용자에 대해 vim에 기본 vi 별칭을 추가하면 어떤 해가 있습니까? 이 작업을 수행하려면 이를 구현하는 데 사용해야 하는 더 좋은 방법이 있습니까(또는 더 정확하게는 보안상의 이유로 피해야 하는 방법이 있습니까?)

대부분의 경우 루트 계정에 사용할 수 있는 별칭을 추가해도 아무런 해가 없습니다. 어디서 어떻게 하는지 주의 깊게 살펴보세요. 이것안전심리학가설이런 일이 일어날 수도 있겠네요.공격 벡터그리고 여러 방법 중 하나해커시스템. 보안 사고 방식 = 모든 공격 방법을 최소화하거나 방지하므로 별칭이 없습니다.

fwiw, 저는 SLES를 사용하고 RHEL도 사용했습니다. 나는 권한이 없는 사용자에게도 작동하는 별칭을 편집 /etc/bash.bashrc.local하고 추가하는 것을 선호합니다 . /etc/csh.cshrc.local이 두 파일의 소유자는 root.root권한을 가지고 있습니다 -rw-r--r--. 루트의 경우 /root/.bashrc.

별칭은 기본 보안 정책을 우회하지 않으며, 그렇다면 문제는 별칭에 있는 것이 아니라 다른 것에 있는 것입니다.

관련 정보