다중 프로토콜 파일 데이터 액세스와 관련하여 Qumulo가 해결하는 과제 중 하나는 혼합 프로토콜 워크플로를 중심으로 합니다. 사용자가 둘 다에서 동일한 파일에 액세스하는 이러한 워크플로 관리 NFS 과 SMB 프로토콜은 파일을 처리하는 방법입니다. 권한.
NFS를 통해 파일에 액세스하는 POSIX 사용자는 SMB를 통해 파일에 액세스하는 Windows 사용자와 다른 권한 동작 집합을 기대합니다. 멀티 프로토콜 환경에서 고객에게 가능한 가장 원활한 워크플로를 만들기 위해 Qumulo는 자동화된 프로토콜 간 권한(XPP) 사용자가 컴퓨팅 플랫폼과 네트워킹 프로토콜 전반에 걸쳐 원활하게 작업할 수 있도록 하는 기능. 이를 통해 Windows, Linux 및 macOS 플랫폼의 사용자는 정교한 권한 보호 및 상속 체계 없이 안전하게 협업할 수 있습니다.
XPP는 XNUMX년이 넘는 기간 동안 많은 엔지니어가 내린 많은 결정으로 구성된 권한 모드입니다. 다중 프로토콜 파일 사용자에게 가능한 한 원활한 권한 경험을 제공하기 위해 POSIX와 NT 권한 간의 고유한 비호환성을 해결합니다. 무엇이 이 문제를 해결하기 어렵게 만들었을까?
파일 시스템 사용자로서 우리는 권한에 대해 너무 많이 생각하지 않는 경향이 있습니다. 그러나 동일한 환경에서 서로 다른 기대치를 갖고 작동하는 완전히 다른 두 프로토콜이 있는 경우 "그냥 작동" 권한을 갖는 것은 엔지니어링 관점에서 많은 생각을 필요로 합니다.
POSIX 대 NT 권한
먼저 약간의 배경. NT 권한은 POSIX 권한보다 훨씬 세분화되어 있습니다. POSIX 권한은 모드 비트를 통해 표시됩니다. 명령줄에서 stat 또는 ls -l을 실행한 적이 있다면 이러한 내용을 본 적이 있을 것입니다. POSIX 모드 비트는 파일 소유자, 그룹 소유자 및 기타 모든 사람을 위해 파일/디렉토리를 읽고, 쓰고, 실행할 수 있는 권한을 표현할 수 있습니다.
| 읽기 | 쓰다 | 실행하다 | |
| 파일 | 파일 읽기 | 추가, 수정 | 파일 실행 |
| 디렉토리 | 목록 디렉토리 | 자식 생성/이름 변경/삭제 | 디렉토리 트래버스(자식 참조) |
POSIX 세계에는 세 가지 기본 권한이 있으며 파일과 디렉토리에 적용될 때 의미가 다릅니다.
반면에 NT 권한은 다음과 같이 표시됩니다. 액세스 제어 목록 (ACL). ACL은 하나 이상의 액세스 제어 항목(ACE), 각각에는 수탁자, 해당 사용자/그룹 및 수탁자가 허용하거나 거부하는 권한 집합이 포함되어 있습니다.
예를 들어, ACE는 DENY bob read 행을 따라 무언가를 표현할 수 있습니다.
ACL에 대한 몇 가지 중요한 사항:
- ACL은 순서대로 평가됩니다. ACL에서 수탁자에게 적용되는 첫 번째 ACE는 해당 수탁자에게 적용될 수 있는 모든 후속 ACE보다 우선합니다.
- Windows에서 가능한 권한은 읽기, 쓰기 및 실행보다 더 세분화되어 있습니다. 14개의 다른 권한을 합친 것과 동일한 "전체 제어" 권한을 포함하여 총 13개의 가능한 권한이 있습니다.
- ACL은 파일/디렉토리별로 적용되며 항목은 상위 디렉토리에서 하위 디렉토리로 전달될 수 있습니다. 상위 디렉토리에서 전달된 ACE를 "상속"이라고 하고, 그렇지 않으면 문제의 파일에 직접 적용된 ACE를 "명시적"이라고 합니다. ACE에는 상속 방법 및 여부를 나타내는 플래그가 있습니다.
- Windows는 명시적 및 상속된 ACE가 ACL에 표시되어야 하는 순서를 지정하는 표준 ACL의 개념을 적용합니다. 표준 순서 ACL은 다음과 같습니다.
명시적 거부
명시적 허용
상속된 거부
상속된 허용
위의 이 스크린샷은 Windows에서 가능한 권한을 보여줍니다.
Qumulo 파일 데이터 플랫폼 및 교차 프로토콜 권한
POSIX 모드 비트와 NT ACL 간의 상당한 차이를 감안할 때 Qumulo는 권한을 어떻게 처리합니까? QACL이라고 하는 자체 버전의 ACL이 있습니다. NT ACL에 거의 1:1로 매핑하고 POSIX 및 Windows에서 표현할 수 있는 권한의 상위 집합을 저장하고 이해합니다.
NT와 POSIX 권한 모델 간의 불일치는 모드 비트 표시, 권한 변경, 파일 생성, 파일 소유자 변경의 네 가지 작업으로 요약할 수 있습니다. 이 게시물에서는 XPP가 이러한 불일치를 해결하는 방법을 이해하기 위해 모드 비트를 표시하고 권한을 변경하는 방법을 구체적으로 살펴보겠습니다.
특정 권한 작업에 대해 더 자세히 설명하기 전에 XPP가 해결하는 근본적인 문제 중 하나는 권한 집합이 적용되는 사용자를 결정하는 방법이라는 점에 유의하는 것이 중요합니다. 이것은 프로토콜에 관계없이 사실입니다. 다음과 같은 고가용성 분산 파일 시스템 Qumulo의 파일 데이터 플랫폼, 잠재적으로 여러 ID 소스(예: LDAP, Active Directory, Qumulo의 로컬 사용자/그룹)가 있는 경우 사용자가 내부적으로 저장되고 식별되는 방식 때문에 누가 누구인지 구분하기 어려울 수 있습니다.
XPP를 통해 Qumulo는 POSIX 확장 또는 사용자 정의 매핑이 있는 Active Directory, OpenLDAP 및 Qumulo의 로컬 사용자/그룹과 같은 ID 소스에서 공통 식별자로 POSIX UID/GID를 사용하는 ID 동등성을 도입했습니다. 이를 통해 이러한 값을 비교하여 누군가가 누구이며 어떤 그룹에 속해 있는지 파악할 수 있습니다.
POSIX 모드 표시
이제 Qumulo는 QACL 형식으로 권한을 저장합니다. 이것은 POSIX 모드를 디스크에 값으로 저장하지 않는다는 것을 의미합니다. NFS를 통해 Qumulo에 액세스하는 사용자가 특정 파일의 모드 비트를 보고자 할 때 QACL에서 생성합니다. 이것은 QACL이 POSIX 사용자/그룹/모든 사람과 정확히 일치하는 수탁자를 지정하는 경우에만 간단하지만 다른 "추가" 수탁자가 있는 경우에는 더 복잡해집니다.
파일 소유자 읽기 허용
파일 그룹 소유자 읽기 허용
모든 사람이 읽을 수 있도록 허용
이 간단한 ACL에서는 표시할 POSIX 모드를 쉽게 알 수 있습니다. 소유자, 그룹 소유자 및 모든 사람은 모두 읽기 권한을 가집니다. 이는 444로 변환됩니다. 그러나 ACL이 다음과 같이 표시되면 어떻게 될까요?
파일 소유자 읽기 허용
파일 그룹 소유자 읽기 허용
모든 사람이 읽을 수 있도록 허용
Alice가 파일을 읽고, 실행하고, 쓰도록 허용
Alice를 가리키는 "추가" ACE를 어떻게 처리합니까? 가능한 가장 정확한 POSIX 모드를 표시하려면 alice가 파일 소유자인지 및/또는 파일 그룹에 속하는지 알아야 합니다. 이 두 가지 정보를 모두 찾는 것은 가능하지만 비용이 많이 들고 POSIX 모드를 표시하는 상당히 일반적인 작업에 큰 성능 저하를 일으킬 수 있습니다.
특히, Alice가 파일 그룹에 있는지 확인하려면 Alice가 파일 소유자인지 여부를 확인하기 위해 모든 ID 소스를 쿼리하는 것 외에도 파일 그룹과 Alice 모두에 대해 재귀적 그룹 구성원 확장을 수행해야 합니다.
대신 우리 엔지니어링 팀이 하기로 결정한 것은 절충안을 만드는 것입니다. Qumulo는 두 작업 중 비용이 덜 드는 ID 등가 검사를 수행하여 "추가" ACE가 실제로 추가인지 또는 파일 소유자인지 확인하지만 그렇지 않은 경우 추가 수탁자의 권한을 모든 사람 비트에 추가합니다. 따라서 alice가 위의 ACL에서 파일 소유자가 아니라고 가정하고 파일을 지정하면 사용자는 모드 비트 447을 보게 되고 alice의 권한은 모든 사람 비트로 접힙니다.
이것은 처음에는 이상하게 보일 수 있습니다. 모든 사람이 파일에 대한 읽기, 쓰기 및 실행 권한을 가지고 있다는 것은 사실이 아닙니다. 그러나 대신 이 파일의 모드로 444를 표시했다고 상상해 보십시오. 그 모드를 보는 사람은 아무도 쓰기 또는 실행 권한이 없다고 가정할 수 있습니다. 그러나 Alice는 이러한 권한을 가지고 있으며 사용자가 그렇지 않으면 보안 위험을 초래한다고 믿게 만듭니다. 주어진 QACL에 대해 가능한 가장 허용적인 모드를 보여줌으로써 Qumulo는 NFS를 통한 권한을 보는 사용자가 모든 사람은 아닐지라도 누군가가 모든 사람 비트에 표시된 권한을 가지고 있음을 알 수 있도록 합니다.
POSIX 모드 변경
NT 및 POSIX 권한을 함께 작동시키는 문제를 해결할 때 팀이 직면한 또 다른 문제는 NFS를 통해 오는 chmod를 처리하는 방법이었습니다. QACL은 잠재적으로 POSIX 읽기/쓰기/실행을 넘어선 권한과 추가 수탁자 및 복잡한 상속 체계를 가질 수 있음을 기억하십시오.
DENY 앨리스 읽기, 소유권 가져오기(객체 상속)
DENY 찰리 실행/순회
Charlie가 파일을 읽고 쓰기를 허용합니다.
Charlie의 그룹 읽기 허용
모든 사람이 콘텐츠를 읽을 수 있도록 허용
밥 읽기, 쓰기 허용(상속 전용)
이 QACL이 적용되는 파일의 경우 charlie가 소유자입니다. alice의 ACE에 있는 객체 상속 플래그는 모든 하위 파일/디렉토리로 전달되어야 함을 의미하고, bob의 상속 전용 플래그는 전달되어야 하며 현재 파일에 대한 bob의 권한에 영향을 미치지 않아야 함을 의미합니다. 누군가가 chmod 555를 수행할 때 이 QACL을 어떻게 변경합니까?
팀은 XPP를 사용하여 요청된 모드와 기존 QACL을 모두 살펴보고 기존 QACL의 상속 구조를 유지하면서 chmod의 의도를 존중하도록 QACL을 조작하는 알고리즘을 개발했습니다. 예를 들어 위의 모드에 모드 555를 적용한 후 결과 QACL은 다음과 같습니다.
앨리스의 소유권을 거부합니다.
DENY 앨리스 읽기, 소유권 가져오기(객체 상속, 상속 전용)
Charlie 읽기, 실행/순회 허용
Charlie의 그룹 읽기, 실행/순회 허용
ALLOW 모든 사람이 읽고, 실행하고, 트래버스합니다.
밥 읽기, 쓰기 허용(상속 전용)
여기에 무슨 일이 벌어 졌었 나? 요청된 모드 555를 반영하도록 권한이 변경되었습니다. 또한 chmod와 모순되기 때문에 더 이상 존재하지 않는 이전 QACL의 파일 소유자에 대한 DENY 항목이 있었습니다.
이제 다른 ACE를 살펴보겠습니다. 이제 Alice를 위한 XNUMX개의 ACE가 있는 이유는 무엇입니까?
DENY 앨리스 읽기, 소유권 가져오기(객체 상속)
전 후
앨리스의 소유권을 거부합니다.
DENY 앨리스 읽기, 소유권 가져오기(객체 상속, 상속 전용)
첫 번째 ACE는 원래 ACE에서 POSIX가 아닌 권한에 대해 거부된 권한을 유지하고(소유권 획득은 SMB 전용 개념임) 두 번째 ACE는 상속 전용으로 표시된 첫 번째 ACE의 복사본일 뿐입니다. 현재 파일에 영향을 주지 않고 하위 파일 및 디렉토리에 전달됩니다. Bob의 ACE는 처음부터 상속 전용이므로 이 파일의 권한에 영향을 주지 않으며 chmod 이후에도 동일하게 유지됩니다.
결론: 사용자를 위한 다중 프로토콜 파일 데이터 액세스 단순화
교차 프로토콜 권한은 권한 모드하지만 이것이 의미하는 바는 Qumulo 팀이 Qumulo 사용자의 요구 사항에 가장 적합하도록 시도한 많은 결정의 모음이라는 것입니다.
이 문제에 관해서 완벽한 답은 없습니다. 그러나 ID 등가를 사용하고 모드 비트에서 기존 액세스를 숨기지 않도록 선택하고 POSIX 모드 변경 및 생성 시 QACL에 선택적으로 영향을 미침으로써 교차 프로토콜 권한은 사용자에게 간단하고 구성이 필요하지 않은 옵션을 제공합니다. 공장.
자세히 알아보기
- 당사의 데이터 서비스 방법 이해 방대한 양의 파일 데이터를 더 쉽게 관리할 수 있습니다.
- 기술 개요 읽기 Qumulo의 고성능 파일 데이터 플랫폼에 대해 알아보세요.
문의하기
- 시승하기. 새로운 대화형 Hands-On Labs에서 Qumulo를 데모하거나 데모 또는 무료 평가판을 요청하십시오.
- Qumulo 블로그 구독 고객 사례, 기술 통찰력, 업계 동향 및 제품 뉴스를 제공합니다.
