프로덕션 서버에 zsh를 설치하는 것이 일반적입니까? [폐쇄]

zsh이는 단지 셸일 뿐이며 서비스를 시작하지 않으며 setuid 명령도 함께 제공되지 않습니다. 따라서 패키지를 설치하는 것만으로는 누군가 또는 무언가가 실제로 패키지를 사용할 때까지 아무 작업도 수행되지 않습니다. 어떠한 권한도 필요하지 않으므로 모든 사용자는 자신의 홈 디렉터리나 액세스할 수 있는 어느 곳에나 직접 설치할 수 있습니다.

그렇지 않다면생산 품질, 관리자용 로그인 셸로 사용하면 약간의 위험이 따른다고 말할 수도 있지만 구문이 bash또는 같은 다른 셸보다 더 합리적 이므로 tcsh많은 개선이 있을 것이라고 생각합니다.

주요 용도는 대화형 셸이지만, 스크립트를 작성하는 것이 zsh아마도 더 안전하고 신뢰할 수 있다고 생각합니다(변수 인용을 잊어버렸을 때 자신도 모르게 구문이 포함된 스크립트를 작성하는 사람이 얼마나 많은지, 그리고 많은 사람들을 수정하기 위해 shebang을 변경하는 방법을 bash살펴보십시오 . 스크립트에 버그가 있음).bashzsh#! /bin/bash#! /bin/zsh -

그럼에도 불구하고, 설치는 zsh제가 근무한 모든 서버 배포에서 가장 먼저 수행하는 작업 중 하나입니다.

그러나 일부 소프트웨어에서는 bash 중심 환경을 기대하는 것이 일반적이므로 일반적으로 모든 사용자의 기본 로그인 셸로 설정하지 않습니다.

다른 사람들과 마찬가지로 내 의견은 다음과 같습니다.

1. 프로덕션 서버에 zsh를 설치하는 것이 안전한가요?

"무해한"을 정의하십시오. 엄밀히 말하면 직접적인 피해는 없습니다. 그러나 프로덕션 시스템의 모든 코드는 잠재적인 공격 벡터입니다. 이런 의미에서 실제로 "무해한" 것은 아닙니다.할 수 있다시스템을 공격하는 데 사용됩니다. 간접적으로 문제를 일으킬 수 있는 몇 가지 다른 방법이 있습니다. 예를 들어, ZSH는 bash보다 리소스 집약적이므로 용량에 가깝게 실행되는 시스템에 중요할 수 있습니다.

2. 이 경우 zsh 설치를 허용하시겠습니까? 왜?

상황에 따라 설치했을 수도 있습니다.

모든 개인 시스템에 ZSH를 설치하고 모든 사람(루트 포함)의 기본 셸로 설정했습니다. 이는 제가 종종 이러한 시스템에서 로컬 셸을 사용하여 작업하고 많은 상황에서 ZSH를 적극적으로 사용하기 때문입니다.

하지만 제가 직장에서 관리하는 시스템에는 이 기능이 설치되어 있지 않습니다. 제가 수행한 관리 작업의 약 95%는 실제로 해당 시스템의 쉘을 건드리는 것과 관련이 없었습니다.많은Ansible을 통해 작업)이므로 익숙한 환경으로 만들 필요가 없습니다. 또한 실제 개발 시스템이 아닌 다른 시스템에 설치할 수 없으며 오프사이트에서 직접 액세스할 수 있는 시스템에 설치할 수 있는 방법도 없습니다.

3. 프로덕션 서버에서 bash를 사용하는 사용자를 제한하는 것이 합리적입니까?

실제 쉘 액세스와 관련되지 않은 일부 매우 엄격한 상황을 제외하고는 일반 사용자에게 프로덕션 시스템에 대한 액세스 권한을 부여하는 것이 실용성에 의문을 제기합니다.

예를 들어, 제가 일하는 곳에서는 IT 부서와 웹사이트 유지 관리를 직접 담당하는 직원만이 웹 서버에 대한 정기적인 HTTPS 액세스 권한을 갖고 있습니다. IT 직원(저 포함)은 웹 서버 관리 전용 계정으로 로그인해야 하며, 이 경우에도 서버실의 물리적 콘솔에 앉아 있지 않는 한 시스템 접근이 제한됩니다. 웹 디자이너는 SFTP를 통해서만 웹사이트의 루트 디렉토리에 접근할 수 있습니다.아무것도 없다다른 것. 이를 감안할 때 bash(내부적으로 사용하는 표준) 외에는 쉘이 필요하지 않습니다.

마찬가지로 IT 부서만이 내부 파일 서버에 대한 실제 셸 액세스 권한을 갖고 있습니다. 다른 사용자는 특정 디렉터리에 대한 액세스를 특별히 제한하여 일반적으로 일반 파일 서버 프로토콜(SMB, NFS 등)과 SFTP 및 경우에 따라 rsync를 허용하지만 실제로는 필요하지 않기 때문에 실제로 쉘 액세스 권한이 있는 사용자는 없습니다. .

내 경험상 프로덕션 서버에 zsh를 설치하는 것은 흔하지 않습니다. 즉, 저는 주로 "보수적인" 고객(은행, 정부 기관 등)과 협력하므로 귀하의 상황은 다를 수 있습니다.

1. Zsh 자체는해가없는. bash, ksh와 같은 "또 다른 셸"일 뿐입니다. 그러나 많은 회사의 보안 정책은 다음과 같습니다.공격 표면을 최대한 제한하세요.즉, 필요하지 않으면 아무것도 설치하지 마세요. zsh는 무해하지만코드 베이스에 버그가 있을 수 있습니다.. 읽다쉘 쇼크아직 모르신다면. :)
   그러나 vi 대신 vim을 사용하는 것과 같이 "상품"에 대한 어느 정도 관용이 있습니다. Zsh는 아마도 이 범주에 속할 것입니다.

2. 생산에 투입되지 않음, 일어나지 않았습니다. 공격 표면을 줄이는 것 외에도 스크립트를 두 번 테스트해야 합니다. 한 번은 zsh로, 한 번은 bash로 테스트해야 합니다. 시간과 돈이 필요합니다.
   

3. 나는 그것을 bash 제한이라고 부르지 않을 것입니다.zsh에서는 할 수 있지만 bash에서는 할 수 없는 것이 있나요?
   

최종 참고사항:bash는 거의 업계 표준입니다. 이는 대부분의 엔터프라이즈 수준 배포판(RHEL, SUSE 등)뿐만 아니라 널리 사용되는 많은 배포판(예: Debian, Ubuntun)의 기본 셸입니다.
수년에 걸쳐 저는 "새로운" 쉘인 zsh와 Fish를 사용해 보았는데 둘 다 제가 정말 좋아합니다. 그러나 가정에서 사용하는 경우 직장에서는 항상 bash(또는 AIX 등으로 작업할 때는 ksh)일 것입니다. 결국 집에서도 bash를 사용하게 되었는데, 오래된 습관은 쉽게 사라지지 않습니다.

다른 의견도 있지만 이건 내꺼다.

1. 프로덕션 서버에 zsh를 설치하는 것이 안전한가요?

새로운 소프트웨어를 도입하는 것이 무해한 경우는 거의 없습니다. 예를 들어, 이와 관련된 모든 취약점을 식별하고 패치해야 합니다.

2. 이 경우 zsh 설치를 허용하시겠습니까? 왜?

아니요. 실질적인 이점을 확인하고 싶습니다.

3. 프로덕션 서버에서 bash를 사용하는 사용자를 제한하는 것이 합리적입니까?

네, bash좋아요 :-) 회사의 일부 틈새 사용자가 zsh광범위한 지원 팀이 알지 못하는 사이에 스크립트를 작성하기 시작하면 그들은 흥분할 것입니다.