'소유자'권한이 존재하는 이유가 있습니까? 그룹 권한이 충분하지 않습니까?

Linux에서 파일 권한이 어떻게 작동하는지 이해하고 있다고 생각합니다. 그러나 나는 왜 그들이 두 가지가 아닌 세 가지 수준으로 나뉘어져 있는지 이해하지 못합니다.

다음 문제에 답하고 싶습니다.

• 이 의도적 인 디자인입니까 아니면 패치입니까? 즉, 소유자 / 그룹 권한이 일부 이론적 근거와 함께 설계되고 작성 되었습니까? 아니면 필요에 따라 차례로 접근 했습니까?
• 사용자 / 그룹 / 기타 구성표는 유용하지만 그룹 / 기타 구성표로는 충분하지 않은 시나리오가 있습니까?

첫 번째 답변은 교과서 나 공식 토론 게시판을 인용해야합니다.

내가 고려한 사용 사례는 다음과 같습니다.

• 개인 파일-많은 시스템에서 자주 수행되는 사용자 별 그룹을 만들어서 쉽게 얻을 수 있습니다.
• 소유자 (예 : 시스템 서비스) 만 파일에 쓸 수 있도록 허용하고 특정 그룹 만 읽고 다른 모든 액세스를 거부 할 수 있습니다.이 예의 문제점은 일단 그룹 이 쓰기 액세스 권한을 갖기 위해서는 사용자가 / group / other가 실패합니다. 두 가지 모두에 대한 답은 ACL을 사용하는 것이며 소유자 권한의 존재를 정당화하지는 않습니다.

NB 나는 superuser.com 에서 질문을 마친 후이 질문을 수정했습니다 .

편집 수정 "하지만 그룹 / 소유자 방식하지 않습니다 충분할"을 "... 그룹 / 기타 ...".

역사

원래 Unix는 소유 사용자와 다른 사용자에 대한 권한 만 가지고있었습니다. 그룹이 없었습니다. 특히 Unix 버전 1의 설명서를 참조하십시오 chmod(1). 따라서 이전 버전과의 호환성을 위해서는 소유하는 사용자에 대한 권한이 필요합니다.

그룹은 나중에왔다. 파일 권한에 둘 이상의 그룹을 포함시킬 수있는 ACL이 훨씬 후에 나왔습니다.

표현력

파일에 대한 세 가지 권한이 있으면 매우 저렴한 비용으로 (ACL보다 훨씬 저렴한) 두 가지보다 세밀한 권한을 허용합니다. 예를 들어, 파일은 rw-r-----소유 한 사용자 만 쓸 수 있고 그룹에서 읽을 수있는 mode : 모드를 가질 수 있습니다 .

다른 유스 케이스는 한 그룹에서만 실행할 수있는 setuid 실행 파일입니다. 예를 들어, rwsr-x---소유 한 모드의 프로그램 root:admin은 admin그룹의 사용자 만 해당 프로그램을 루트로 실행할 수 있습니다.

“이 체계가 표현할 수없는 권한이있다”는 것은 그에 대한 끔찍한 주장이다. 적용 가능한 기준은 비용을 정당화 할 수있는 일반적인 표현 가능한 사례가 충분히 있습니까? 이 경우, 특히 사용자 / 그룹 / 다른 삼부작에 대한 다른 이유를 고려할 때 비용이 최소화됩니다.

간단

사용자 당 하나의 그룹을 갖는 것은 작지만 중요하지 않은 관리 오버 헤드가 있습니다. 개인 파일의 극단적 인 경우는 이것에 의존하지 않는 것이 좋습니다. 개인 파일 (예 : 이메일 전송 프로그램)을 만드는 응용 프로그램은 파일 600에 모드를 지정하기 만하면됩니다. 사용자 만 포함하는 그룹을 찾기 위해 그룹 데이터베이스를 탐색 할 필요는 없습니다. 그러한 그룹이 없거나 둘 이상이 아닌 경우 어떻게해야합니까?

다른 방향에서 온 파일을보고 해당 파일의 권한을 감사하고 싶다고 가정합니다 (예 : 파일이 무엇인지 확인). 그룹 정의를 추적해야 할 때보 다 "사용자 만 액세스 할 수 있고, 다음에 더 좋다"는 것이 훨씬 쉽습니다. (이러한 복잡성은 ACL 또는 기능과 같은 고급 기능을 많이 사용하는 시스템의 단점입니다.)

직교성

각 프로세스는 특정 사용자 및 특정 그룹 (보조 그룹을 지원하는 최신 유니스에 대한보다 복잡한 규칙)으로 파일 시스템 액세스를 수행합니다. 사용자는 루트 (uid 0) 및 신호 전달 권한 (사용자 기반) 테스트를 포함하여 많은 용도로 사용됩니다. 프로세스 권한에서 사용자와 그룹을 구별하는 것과 파일 시스템 권한에서 사용자와 그룹을 구별하는 것은 자연스러운 대칭입니다.

이 의도적 인 디자인입니까 아니면 패치입니까? 즉, 소유자 / 그룹 권한이 일부 이론적 근거와 함께 설계되고 작성 되었습니까? 아니면 필요에 따라 차례로 접근 했습니까?

파일에 대한 사용자 / 그룹 / 기타 권한은 원래 Unix 디자인의 일부입니다.

사용자 / 그룹 / 기타 구성표는 유용하지만 그룹 / 소유자 구성표로는 충분하지 않은 시나리오가 있습니까?

예, 거의 모든 시나리오에서 보안 및 액세스 제어가 중요한 곳을 상상할 수 있습니다.

예 : 시스템의 일부 바이너리 / 스크립트에에 실행 전용 액세스 권한을 부여 other하고 읽기 / 쓰기 액세스 권한을로 유지하려고 할 수 root있습니다.

소유자 / 그룹 권한 만있는 파일 시스템 권한 모델에 대해 무엇을 염두에두고 있는지 잘 모르겠습니다. other카테고리가 없는 안전한 운영 체제를 가질 수있는 방법을 모르겠습니다 .

편집 : 여기에 group/other권한이 필요한 모든 것을 의미한다고 가정하면 암호 키를 관리하는 방법이나 올바른 사용자 만 메일 스풀에 액세스 할 수있는 방법을 고안하는 것이 좋습니다. 개인 키는 엄격하게 user:user소유권 이 필요할 수 있지만 다른 경우에는 키를 소유하는 것이 합리적 user:group입니다.

개인 파일-많은 시스템에서 자주 수행되는 사용자 별 그룹을 만들어서 쉽게 얻을 수 있습니다.

이것은 쉽게 이루어 지지만 other그룹 의 존재와 마찬가지로 쉽게 이루어집니다 ...

소유자 (예 : 시스템 서비스) 만 파일에 쓸 수 있도록 허용하고 특정 그룹 만 읽고 다른 모든 액세스를 거부 할 수 있습니다. 이 예의 문제점은 일단 그룹이 쓰기 액세스 권한을 갖기 위해서는 사용자가 / group / other가 실패합니다. 두 가지 모두에 대한 답은 ACL을 사용하는 것이며 소유자 권한의 존재를 정당화하지는 않습니다.

otherUnix 파일 시스템 권한 의 범주에 대한 논리적 필요성에 대한 요점을 되풀이하는 귀하의 진술 부분을 강조했습니다 .

당신이 생각하는 것처럼 보이는 파일 시스템 디자인은 (내가 말할 수있는 것에서) 안전하지 않거나 다루기 어려울 것입니다. 유닉스는 매우 똑똑한 사람들에 의해 설계되었으며 그들의 모델은 최상의 보안과 유연성의 균형을 제공한다고 생각합니다.

이 의도적 인 디자인입니까 아니면 패치입니까? 즉, 소유자 / 그룹 권한이 일부 이론적 근거와 함께 설계되고 작성 되었습니까? 아니면 필요에 따라 차례로 접근 했습니까?

예, 이것은 초기부터 유닉스에 존재했던 고의적 인 디자인입니다. 메모리가 KB 단위로 측정 된 시스템에서 구현되었으며 오늘날 표준에 따라 CPU 속도가 매우 느립니다. 이러한 검색의 크기와 속도가 중요했습니다. ACL은 더 많은 공간을 필요로하고 느려졌을 것입니다. 기능적으로 everyone그룹은 다른 보안 플래그로 표시됩니다.

사용자 / 그룹 / 기타 구성표는 유용하지만 그룹 / 소유자 구성표로는 충분하지 않은 시나리오가 있습니까?

파일 액세스에 일반적으로 사용하는 권한은 다음과 같습니다. (단순화를 위해 비트 값을 사용하고 있으며 이것이 일반적으로 설정하는 방식이므로)

• 600또는 400: 사용자 전용 액세스 (그렇습니다. 사용자에게 읽기 전용 액세스 권한을 부여합니다).
• 640또는 660: 사용자 및 그룹 액세스.
• 644, 666또는 664: 사용자, 그룹 및 기타 액세스 할 수 있습니다. 두 가지 수준의 권한 체계는이 세 가지 경우 중 두 가지만 처리 할 수 ​​있습니다. 세 번째는 ACL이 필요합니다.

내가 일반적으로 사용하는 디렉토리 및 프로그램의 경우 :

• 700또는 500: 사용자 전용 액세스
• 750또는 710: 그룹 전용 액세스
• 755, 777, 775, 또는 751: 사용자, 그룹 및 기타 액세스 할 수 있습니다. 파일과 동일한 설명이 적용됩니다.

위의 항목이 가장 일반적으로 사용되지만 사용하는 전체 권한 설정 목록은 아닙니다. ACL과 함께 사용했던 모든 경우에 그룹과 결합 된 위의 권한 (경우에 따라 디렉토리에 고정 그룹 비트가있는 경우)이 충분했습니다.

위에서 언급 한 것처럼 디렉토리 목록에 권한을 나열하는 것은 매우 쉽습니다. ACL을 사용하지 않으면 디렉토리 목록만으로 액세스 권한을 감사 할 수 있습니다. ACL 기반 시스템으로 작업 할 때 권한을 확인하거나 감사하기가 매우 어렵다는 것을 알게되었습니다.

사용자 / 그룹 / 기타 권한 시스템은 ACL이 발명되기 전에 설계되었습니다. 유닉스 초기로 거슬러 올라가므로 ACL로 문제를 해결해야한다고 말할 수는 없습니다. ACL의 개념이 명백해 보일지라도, 고정 된 양이 아닌 각 파일과 함께 다양한 양의 권한 정보를 저장하고 관리하는 데 상당한 양의 추가 오버 헤드가 수반되었을 것입니다.

모든 것을 위해 ACL을 사용한다는 것은 "한 눈에"보여 질 수있는 권한 정보의 잘 정의 된 부분 집합이 없다는 것을 의미합니다. 의 출력 ls -l을 보여줍니다 표준 (사용자 / 그룹 / 기타) 권한, 사용자 및 그룹의 이름 및 추가 표기 (예 +또는 @ACL에 그들과 관련이 항목에 대한 기호), 한 줄의 모든. 시스템은 동등한 기능을 제공하기 위해 ACL에서 "상위 2 개"그룹을 식별해야합니다.

추가로, UNIX ACL은 ACL을 수정할 수있는 사용자를 제공하지 않기 때문에 파일에는 여전히 UNIX 모델에 소유자 가 있어야 합니다.