나는 Linux에서 파일 권한이 어떻게 작동하는지 더 잘 이해하고 있다고 생각합니다. 그런데 왜 2단계가 아닌 3단계로 나누어져 있는지 잘 모르겠습니다.
나는 다음 질문에 답하고 싶습니다.
- 이건 의도적인 디자인인가요 아니면 패치인가요? 즉, 소유자/그룹 권한은 이유가 있어서 설계되고 생성되었습니까? 아니면 필요를 충족하기 위해 차례로 등장했습니까?
- 사용자/그룹/기타 구성표가 유용하지만 그룹/기타 구성표로는 충분하지 않은 상황이 있습니까?
첫 번째 질문에 대한 답변은 교과서나 공식 토론 게시판을 인용해야 합니다.
내가 고려한 사용 사례는 다음과 같습니다.
- 개인 파일 - 많은 시스템에서 흔히 수행되는 각 사용자에 대한 그룹을 생성하여 쉽게 얻을 수 있습니다.
- 소유자(예: 시스템 서비스)만 파일에 쓸 수 있도록 허용하고, 특정 그룹만 읽을 수 있도록 허용하며, 다른 모든 액세스는 거부합니다. 이 예의 문제는 일단 요청한 것입니다.그룹쓰기 액세스 권한을 얻으려면 사용자/그룹/기타가 실패합니다. 두 가지 모두에 대한 대답은 IMHO가 소유자 권한의 존재를 증명하지 않는 ACL을 사용하는 것입니다.
참고: 이 질문이 끝난 후 개선되었습니다.슈퍼유저 웹사이트.
편집하다"그러나 그룹/소유자 체계로는 충분하지 않습니다"를 "...그룹/기타..."로 수정했습니다.
답변1
역사
처음에 Unix는 자신이 속한 사용자와 다른 사용자에 대해서만 권한을 가졌습니다. 그룹은 없었습니다. 특히 Unix 버전 1에 대한 설명서를 참조하세요.chmod(1). 따라서 다른 이유가 없다면 이전 버전과의 호환성을 위해서는 사용자의 권한이 필요합니다.
그룹은 나중에 왔습니다. 여러 그룹이 파일에 대한 권한에 참여할 수 있도록 허용하는 ACL은 훨씬 나중에 나타났습니다.
표현력
파일에 대한 세 가지 권한이 있으면 파일이 두 개만 있는 것에 비해 매우 저렴한 비용(ACL보다 훨씬 낮음)으로 더 세분화된 권한이 가능합니다. 예를 들어, 파일에는 모드가 있을 수 있습니다 rw-r-----. 즉, 소유한 사용자만 쓸 수 있고 그룹에서는 읽을 수 있습니다.
또 다른 사용 사례는 그룹에서만 실행할 수 있는 setuid 실행 파일입니다. 예를 들어, rwsr-x---모드가 있는 프로그램은 그룹의 사용자 root:admin만 루트로 프로그램을 실행할 수 있도록 허용합니다 .admin
"이 계획으로는 표현할 수 없는 권리가 있습니다"라는 말은 끔찍한 반대입니다. 적용 가능한 표준은 비용을 정당화할 만큼 공통적으로 표현 가능한 사례가 충분한가입니다. 이 경우 특히 사용자/그룹/삼부화의 기타 이유를 고려하면 비용이 최소화됩니다.
단순한
사용자당 하나의 그룹에 대한 관리 오버헤드는 작지만 크지 않습니다. 다행스럽게도 매우 일반적인 개인 파일 상황은 이에 의존하지 않습니다. 개인 파일을 생성하는 애플리케이션(예: 이메일 배달 프로그램)은 파일에 모드 600을 지정하기만 하면 된다는 것을 알고 있습니다. 사용자만 포함된 그룹을 찾기 위해 그룹 데이터베이스를 탐색할 필요가 없습니다. 그러한 그룹이 없거나 둘 이상이면 어떻게 될까요?
다른 방향에서 보면, 파일을 보고 그 권한을 감사하고 싶다고 가정해 보겠습니다(즉, 권한이 올바른지 확인). 그룹 정의를 추적해야 할 때보다 "사용자에게만 액세스 가능, 훌륭합니다. 다음 단계"가 가능하면 훨씬 쉽습니다. (이러한 복잡성은 ACL이나 기능과 같은 고급 기능을 많이 사용하는 시스템의 골칫거리입니다.)
직교성
각 프로세스는 특정 사용자 및 특정 그룹으로 파일 시스템 액세스를 수행합니다(보조 그룹을 지원하는 최신 unice에는 더 복잡한 규칙이 있습니다). 사용자는 루트 테스트(uid 0) 및 신호 권한(사용자 기반)을 포함하여 많은 작업에 사용됩니다. 프로세스 권한에서 사용자와 그룹을 구별하는 것과 파일 시스템 권한에서 사용자와 그룹을 구별하는 것 사이에는 자연스러운 대칭이 있습니다.
답변2
이건 의도적인 디자인인가요 아니면 패치인가요? 즉, 소유자/그룹 권한은 이유가 있어서 설계되고 생성되었습니까? 아니면 필요를 충족하기 위해 차례로 등장했습니까?
파일에 대한 사용자/그룹/기타 권한은 원래 Unix 설계의 일부입니다.
사용자/그룹/기타 구성표가 유용하지만 그룹/소유자 구성표로는 충분하지 않은 상황이 있습니까?
예, 제가 상상할 수 있는 거의 모든 시나리오에서는 보안과 액세스 제어가 중요합니다.
예: 시스템의 특정 바이너리/스크립트에 대한 실행 전용 액세스를 제공 other하고 읽기/쓰기 액세스를 제한 할 수 있습니다 root.
소유자/그룹 권한만 있는 파일 시스템 권한 모델에 대해 어떻게 생각하시는지 잘 모르겠습니다. 카테고리 없이 어떻게 안전한 운영 체제를 가질 수 있는지 모르겠습니다 other.
편집하다:
여기에는 권한만 필요하다는 의미라고 가정하면 group/other암호화 키를 관리하는 방법을 고안하거나 올바른 사용자만 메일 스풀에 액세스할 수 있는 방법을 고안하는 것이 좋습니다. 어떤 경우에는 개인 키에 엄격한 user:user소유권이 필요할 수 있지만 다른 경우에는 user:group소유권을 부여하는 것이 합리적입니다.
개인 파일 - 많은 시스템에서 흔히 수행되는 각 사용자에 대한 그룹을 생성하여 쉽게 얻을 수 있습니다.
물론 이것도 쉽지만, 그룹이 있으면 똑같이 쉽습니다 other...
소유자(예: 시스템 서비스)만 파일에 쓸 수 있도록 허용하고 특정 그룹만 읽을 수 있도록 허용합니다.다른 모든 액세스 거부- 이 예의 문제점은 그룹에 쓰기 액세스 권한이 필요한 경우 사용자/그룹/기타 사용자가 이를 얻을 수 없다는 것입니다. 두 가지 모두에 대한 답은 ACL을 사용하는 것입니다. 제 생각에는 이것이 소유자 권한의 존재를 증명하지 못하는 것 같습니다.
other나는 Unix 파일 시스템 권한 범주의 논리적 필요성에 대한 내 주장을 반복하는 것처럼 보이는 귀하의 진술의 일부를 강조했습니다 .
당신이 고려하고 있는 파일 시스템 설계 종류는 (내가 아는 한) 안전하지 않거나 작동하기 어렵습니다. Unix는 매우 똑똑한 사람들에 의해 설계되었으며 그들의 모델은 보안과 유연성 사이에서 최상의 균형을 제공한다고 생각합니다.
답변3
이건 의도적인 디자인인가요 아니면 패치인가요? 즉, 소유자/그룹 권한은 이유가 있어서 설계되고 생성되었습니까? 아니면 필요를 충족하기 위해 차례로 등장했습니까?
예, 이것은 UNIX 초기부터 존재해 온 신중한 설계입니다. 이는 메모리가 KB 단위로 측정되고 CPU가 오늘날 표준에 비해 매우 느린 시스템에서 구현되었습니다. 이러한 조회의 크기와 속도는 중요합니다. ACL에는 더 많은 공간이 필요하고 속도가 더 느립니다. 기능적으로 이 everyone그룹은 다른 보안 기호로 표시됩니다.
사용자/그룹/기타 구성표가 유용하지만 그룹/소유자 구성표로는 충분하지 않은 상황이 있습니까?
제가 파일 접근을 위해 일반적으로 사용하는 권한은 다음과 같습니다. (간단히 비트 값을 보통 그렇게 설정하기 때문에 비트 값을 사용하고 있습니다.)
600또는400: 사용자 액세스만 가능합니다(예, 사용자에게 읽기 전용 액세스 권한을 부여합니다).640또는660: 사용자 및 그룹 액세스.644,666또는664: 사용자, 그룹 및 기타 액세스 권한입니다. 보조 권한 체계는 이 세 가지 경우 중 두 가지만 처리할 수 있습니다. 세 번째에는 ACL이 필요합니다.
일반적으로 사용되는 디렉토리 및 프로그램의 경우:
700또는500: 사용자 액세스만 가능750또는710: 그룹 액세스만 가능755,777,775또는751: 사용자, 그룹 및 기타 액세스 권한입니다. 파일에도 동일한 설명이 적용됩니다.
위의 내용은 가장 일반적으로 사용되지만 제가 사용하는 권한 설정의 전체 목록은 아닙니다. ACL을 사용할 수 있는 모든 경우에 그룹(때때로 디렉터리의 고정 그룹 비트)과 결합된 위의 권한이면 충분합니다.
위에서 언급했듯이 디렉토리 목록에 권한을 나열하는 것은 매우 쉽습니다. ACL을 사용하지 않고 디렉터리 목록만 사용하여 액세스를 감사할 수 있습니다. ACL 기반 시스템을 사용할 때 권한을 확인하거나 감사하는 것이 매우 어렵습니다.
답변4
사용자/그룹/기타 권한 시스템은 ACL이 발명되기 전에 설계되었습니다. 이는 UNIX 초기로 거슬러 올라가므로 ACL로 이 문제를 해결해야 한다고 말할 수는 없습니다. ACL의 개념은 분명해 보이지만 각 파일에 대해 고정된 양이 아닌 가변적인 양의 권한 정보를 저장하고 관리하려면 추가 오버헤드가 많이 필요합니다.
모든 것에 ACL을 사용한다는 것은 "한 눈에" 표시할 수 있는 잘 정의된 권한 정보 하위 집합이 없다는 의미이기도 합니다. 출력에는 ls -l표준(사용자/그룹/기타) 권한, 사용자 및 그룹의 이름, ACL이 연결된 항목의 추가 기호(또는 기호 등)가 +모두 한 줄에 표시됩니다. @시스템에서는 동등한 기능을 제공하기 위해 ACL의 "처음 두" 그룹을 인식해야 합니다.
또 다른 점은 파일이 여전히 필요하다는 것입니다.가지다UNIX 모델의 소유자(UNIX ACL은 ACL 수정이 허용된 사람을 지정하지 않기 때문)