내 연구실에서는 한 그룹의 사람들이 워크스테이션에서 작업하고 NFS를 통해 여러 드라이브를 공유합니다. NFS 드라이브 중 하나에 있는 공유 소프트웨어를 실행하고 데이터가 있는 NFS 드라이브에서 소프트웨어를 실행합니다.
현재 설정에는 동일한 사용자 계정을 사용하는 모든 항목이 있으므로 one모든 호스트에서 호출해 보겠습니다. 연구실 구성원은 joe@myhost자신만의 사용자 정의 설정이 있는 데스크탑을 가지고 로그인 하지만 one과학 데이터에 대한 실제 작업이 그룹에 속하려면 로그인 users해야 합니다 one.
환경의 일부 사용자별 사용자 정의는 one계정을 호스트별로 정의하고 홈 디렉토리를 로컬로 설정함으로써 달성 됩니다 one@myhost:/home/one(역사적 이유로 둘 다 UID 502 및 GID 100임). 따라서 각 사용자의 계정은 one공유 프로그램에 대한 공개 포인터 옆에 특정 환경 변수를 설정할 수 있습니다.PATH
현재 연구실에서 논의가 진행 중이며 Unix에서 더 나은 접근 방식은 다양한 사용자에 대해 별도의 계정을 갖고 그룹을 사용하여 개별 사용자의 현재 기능을 복제하는 것이라고 제안합니다.
단일 계정의 다음과 같은 단점을 나열했습니다.
- 여러 소프트웨어 버전을 관리하는 데 어려움이 있습니다.
- 거의 무의미한 감사/로깅,
- 누구나 다른 사람의 파일과 프로그램을 삭제할 수 있습니다.
- 구성원이 연구실을 떠날 때 비밀번호를 변경하는 것이 좋습니다.
이제 이 네트워크는 방화벽 뒤에 있으며 과학적 데이터일 뿐이며 침입자에게는 아무 의미도 없고 경제적 가치도 없습니다. 또한 빠르게 진행되는 과학 실험실에서는 안전을 포함한 모든 것이 생산성보다 우선합니다. 데이터는 자주 백업되므로 데이터나 프로그램을 삭제하는 기능도 큰 문제가 되지 않습니다.
계정 방식은 너무 편리하고 수년 전(2001년?)에 확립되었기 때문에 one누구에게나 사용자당 하나의 계정을 사용하도록 설득하는 데 어려움을 겪었습니다. 어쩌면 내가 잘못된 주장을 사용하고 있을 수도 있고, 위에서 설명한 시나리오가 접근 one방식이 실용적이고 내 추론이 융통성이 없는 것일 수도 있습니다.
두 경우 모두, 제가 틀렸다는 것을 알아내는 데 도움을 주시면 감사하겠습니다. 아니면 제가 옳다면 제 주장을 논증할 수 있는 방법을 제안해 주십시오.
답변1
글쎄, 나는 별도의 계정에 대한 아이디어에 반대하는 두 가지 주장을 생각할 수 있습니다.
첫째, 클래식 UNIX 그룹은 일반적인 공유 파일 트리에 비해 큰 결함이 있습니다. 즉, 각 사용자와 이들이 실행하는 모든 스크립트에는 파일과 디렉터리 그룹을 쓰기 가능하게 유지하기 위해 umask가 필요하며 모든 디렉터리에 그룹 고정 비트를 적용해야 합니다. . 실제로 이는 많은 스크립트가 제한적인 umask를 지정하고, rsync -a자신이 소유한 디렉토리에 cp -a파일을 공개 트리에 넣으면 tar -x그룹 고정 비트를 추가하고 그룹을 공유하도록 변경하는 것을 잊어버리기 쉽기 때문에 어렵습니다. 결국 Joe가 소유한 파일의 하위 트리가 생성되고 Joe는 휴가 중이거나 점심 먹으러 나갑니다. 누군가 해당 파일을 수정해야 하고 시스템 관리자에게 가서 수정해야 합니다. IMHO, Unix 권한은 간단하고 효율적으로 설계되었지만 현실 세계에서는 그다지 실용적이지 않습니다.
둘째, 이 공용 파일 트리에 바이너리가 포함되어 있고 모든 사람이 해당 경로를 $PATH에 추가하면 보안이 전혀 없습니다. 사용자 중 누구라도 전체 그룹을 하이재킹할 수 있으므로 실제로 서로를 신뢰하는 것이 좋습니다. 또한 NFS를 사용하고 있으므로 사용자가 자신의 워크스테이션에 대한 루트 액세스 권한을 인수할 수 있으면 원하는 다른 사용자처럼 중앙 파일에 액세스할 수 있습니다.
사용자 계정을 취소하려는 아이디어는 비밀번호가 저장되어 있는 로컬 워크스테이션에서 해당 계정을 삭제하면 됩니다 one(맞죠?). 왜냐하면 NFS를 사용하면 파일 서버가 사용자가 어떤 비밀번호를 입력했는지 알 수 없기 때문입니다. 그리고 그들의 워크스테이션 커널이 "안녕하세요, 내 UID는 502입니다. 나를 대신하여 이 작업을 수행하세요"라고 말하는 것만 알 수 있습니다.
따라서 조직에서 이 문제를 추진하기 전에 원하는 것을 실제로 달성할 수 있는지 고려해야 합니다.
프로그램 버전의 혼란을 덜고 싶다면 사용자에게 관리자 소유 버전을 설치하도록 요청할 수도 있습니다. 관리자가 $PATH의 모든 것을 제어하면 보안이 더 좋습니다.
누가 파일을 변경하고 있는지 확인할 수 있도록 별도의 계정을 원하는 경우 INotify(Perl로 작성하는 것이 좋습니다)를 사용하여 공유 트리를 모니터링하는 데몬을 작성하고 g+rwx각 "열기" 후에 이러한 비트 이벤트를 강제로 설정해야 할 수도 있습니다. 각 "쓰기" 이벤트 이후의 UID입니다.
도움이 되길 바랍니다...