역사

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

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

표현력

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

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

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

간단

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

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

직교성

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

답변