요약

  • IMAP 사서함 ACL은 식별자와 권한 항목의 집합입니다. 로그인한 사용자는 자신의 개인 식별자, 하나 이상의 그룹, 그리고anyone에 동시에 일치할 수 있으므로, 하나의 항목은 권한 부여 판단의 입력일 뿐입니다.
  • GETACL은 규칙을 보여주고,LISTRIGHTS는 서버가 특정 식별자에 부여할 수 있는 권한을 보여주며,MYRIGHTS는 현재 사용자에 대한 서버의 실효적 답변을 보여줍니다. 이 세 가지는 의도적으로 서로 다른 질문입니다.
  • DELETEACL은 하나의 항목을 제거합니다. 마이너스 권한 식별자는 계산 과정에서 권한을 차감합니다. RFC 4314는 이 구분을 명확히 했지만, 신원 결합 방식과 마이너스 권한 지원의 일부는 구현별로 남겨두었습니다.

문제를 끝내지 못한 깔끔한 편집

접근 제어 화면은 안심되는 이야기를 유도합니다. 사용자 이름이 적힌 행을 찾아 제거하고 저장하면 그 사용자는 사라진다는 이야기입니다. 이 이야기는 그 행이 사용자의 유일한 권한 경로였고, 실행 중인 시스템이 이미 판단을 다시 계산했을 때만 참입니다.

공유 사서함은 이 약점을 일찍 드러냈습니다. 지원 대응 사서함은 한 팀에 속할 수 있습니다. 한 사람은 직접 부여를 받는 동시에 그룹을 통해 다른 권한을 상속하고, 공개 또는 조직 전체 식별자를 통해 세 번째 권한까지 받을 수 있습니다. 규칙 목록은 접근의 여러 이유를 서술하지만, 그 자체가 최종 답변은 아닙니다.

RFC 1730은 원격 사서함을 조작 가능한 네트워크 객체로 만들었습니다. 클라이언트는 폴더를 선택하고 메시지를 읽고 플래그를 설정하며 서버의 사서함 상태를 변경할 수 있게 되었습니다. 한 객체를 여러 사람이 다룰 수 있게 되자, 접근 제어도 프로토콜을 통해 전달되어야 했습니다. 서버 운영자만 볼 수 있는 로컬 파일시스템 권한으로는 사용자가 무엇을 할 수 있는지 확인해야 하는 원격 메일 클라이언트를 충족할 수 없었습니다.

1997년 1월 표준 트랙(Standards Track)으로 발표된RFC 2086이 바로 그 표면을 추가했습니다. 서버는 자신의 기능 목록에ACL을 공표했습니다. 이 확장은 사서함 ACL을 식별자와 권한 문자열의 쌍(pair) 집합으로 정의했습니다. 클라이언트는 서버의 전체 계정 데이터베이스를 들여다보지 않고도 이러한 쌍을 조회하거나 수정할 수 있었습니다.

하나의 세션이 여러 이름으로 도달할 수 있었다

쌍의 단순해 보이는 모습 뒤에는 핵심 설계 문제가 숨어 있었습니다. RFC 2086은 익명 접근을 포함하는 보편적 신원을 위해anyone을 예약했습니다.LOGIN이나AUTHENTICATE가 받아들이는 사용자 이름은 해당 사용자를 대표했습니다. 다른 식별자는 그룹이나 기타 로컬에 정의된 주체를 뜻할 수 있었습니다.

이런 식별자 여러 개가 동일한 세션에 적용될 수 있었습니다. Fred는fred,support-team,anyone과 동시에 일치할 수 있습니다. RFC는 하나의 보편적인 결합 알고리즘을 강제하지 않았습니다. 어떤 서버는 적용 가능한 모든 부여의 합집합을 취하고, 다른 서버는 가장 구체적으로 일치하는 식별자만 사용할 수 있습니다. 그 선택은 구현과 그 현지 보안 모델에 속했습니다.

이는 클라이언트가 안전하게 채울 수 있는 공백이 아니었습니다. 그래픽 편집기는 행을 표시할 수 있지만, 실행 중인 서버의 그룹 소속, 소유자 강제 권한, 우선순위 규칙을 추론할 수 없습니다. 따라서 동일하게 보이는 목록이 서로 다른 두 개의 적합한 시스템에서 서로 다른 실효적 결과를 낼 수 있었습니다.

프로토콜의 답은 신원을 중앙화하는 것이 아니라 최종 계산을 노출하는 것이었습니다.MYRIGHTS mailbox는 서버에게 로그인한 사용자가 그 사서함에 실제로 가진 권한이 무엇인지 묻습니다. 그 응답은 다음 명령을 집행할 구성 요소가 내놓는 실행 상태에 대한 증거였습니다.

세 가지 질의, 세 겹의 현실

이 확장은 관리 도구가 흔히 하나로 뭉개는 질문들을 분리했습니다.

GETACL은 사서함에 저장된 식별자-권한 항목을 반환했습니다. 이것이 답하는 질문은 “여기에 어떤 규칙이 선언되어 있는가?”입니다. 어떤 항목이 현재 사용자에게 적용되는지, 서버가 그것을 어떻게 결합하는지는 말하지 않습니다.

LISTRIGHTS는 사서함과 식별자를 받아 어떤 권한을 부여할 수 있는지 보고합니다. 어떤 권한은 필수일 수 있고, 하위 구현이 서로 분리할 수 없어 묶음(tied set)으로 제시되는 권한도 있었습니다. 이것이 답하는 질문은 “이 서버는 이 주체에 대해 어떤 변경을 표현할 수 있는가?”입니다.

MYRIGHTS는 현재 사용자의 실효적 권한을 반환했습니다. 이것이 답하는 질문은 “신원 매칭과 로컬 결합을 거친 뒤, 이 세션이 무엇을 할 수 있다고 집행 서버가 말하는가?”입니다.

이 구분이 중요한 이유는, 관리 패널이 자신의 모델을 성공적으로 바꾸면서도 권한을 바꾸지 못할 수 있기 때문입니다. 규칙 재조회는 저장되었음을 증명합니다.MYRIGHTS재조회는 하나의 세션에 대한 서버의 현재 계산을 증명합니다. 실제 사서함 작업을 시도해야만 관련 동작이 수락되었는지 확인할 수 있으며, 그조차 자격 증명 뒤의 사람이 누구인지는 밝혀주지 못합니다.

삭제는 이유를 제거했지, 결과를 반드시 제거한 것은 아니었다

DELETEACL mailbox fred는fred의 쌍을 제거합니다. Fred가support-team이나anyone을 통해 여전히w를 유지한다면, 삭제는 이름이 말하는 것을 정확히 수행하면서 실효적 쓰기 권한은 그대로 둡니다.

RFC 2086은 또한 대시로 시작하는 식별자를 마이너스 권한을 위해 예약했습니다. RFC 4314는 그 목적을 더 분명하게 했습니다.-fred에w가 붙은 항목은, 다른 일치하는 신원이 그렇지 않으면 공급했을 쓰기 권한을 Fred와 연관된 권한에서 차감합니다. 마이너스 항목은 계산에 참여하며,DELETEACL은 양(+) 항목이든 마이너스 항목이든 하나의 쌍을 제거할 뿐입니다.

마이너스 권한 지원은 선택 사양으로 남았습니다. 이것이 중요합니다. 프로토콜에 차감 표기법이 있다는 이유만으로 클라이언트가 보편적인 “거부가 허용을 이긴다” 버튼을 약속할 수는 없습니다. 먼저 서버가 무엇을 지원하는지 확인하고, 그다음 실효적 결과를 검증해야 합니다.

마이너스 기호의 두 가지 용법도 구분된 상태로 남아야 했습니다.SETACL의 권한 인수에서-w는 선택된 항목에서w를 제거한다는 뜻입니다. 식별자 위치에서-fred는 마이너스 권한 항목을 뜻합니다. 전자는 하나의 행을 편집하고, 후자는 계산이 권한을 어떻게 차감할 수 있는지를 바꿉니다. 표기가 비슷하다고 두 작업이 같아지지는 않았습니다.

기존 클라이언트를 버리지 않으면서 권한은 더 세백해졌다

첫 확장은 압축된 문자를 사용했습니다. 조회(lookup), 읽기, 읽음 상태, 기타 플래그 쓰기, 삽입, 발송(post), 생성, 삭제, 관리(administer)가 그것입니다. 일부 경계는 너무 넓었습니다. 예컨대 사서함 전체의 삭제를c가 제어하는지d가 제어하는지에 대해 구현들이 서로 달랐습니다.

2005년 12월에RFC 4314가 RFC 2086을 대체하며 애매한 작업들을 쪼갰습니다.k는 하위 사서함 생성을,x는 사서함 삭제 또는 이동을,t는 메시지 삭제 플래그 설정을,e는 메시지 영구 삭제(expunge)를 각각 제어했습니다. 기존의c와d는 가상 호환 권한으로 살아남아, 오래된 클라이언트가 이해할 수 있는 투영을 받는 동안 새로운 서버는 더 세백한 구분을 집행할 수 있었습니다.

이 마이그레이션은 프로토콜의 절제에 대한 작은 역사입니다. 개정은 배포된 소프트웨어를 즉시 교체할 수 있다고 가장하지 않았습니다. 새 모델에서 권한을 좁히고, 추가 권한을RIGHTS=를 통해 알리며, 기존 구현을 위해 손실이 있지만 정의된 뷰를 유지했습니다.

개정은 새 편집기에도 규칙을 부과했습니다. 사용자가 나머지 권한을 편집할 수 있게 한다면, 이해하지 못하는 권한은 보존하라는 규칙이었습니다. 그렇지 않으면 새 권한이 존재하기 전에 만들어진 클라이언트가 항목을 읽고 자신이 인식하는 문자만 다시 써 넣으며 알 수 없는 부여를 조용히 파괴할 수 있습니다. 확장성을 유지하려면 무지가 보수적이어야 했습니다.

회수에도 시간 경계가 있었다

정확한 실효 권한 변경조차 이미 선택된 사서함에 즉시 적용되지 않을 수 있었습니다. RFC 4314는 사서함이 선택되어 있는 동안 서버가 권한을 캐시할 수 있도록 했습니다.SETACL또는DELETEACL이후에도STORE나EXPUNGE같은 작업은 사서함이 다시 선택될 때까지 캐시된 판단에 따라 계속 진행될 수 있었습니다.

모든 명령을 검사하는 서버는 갱신된 플래그를 보내거나, 선택 상태의 작업을 거부하거나, 읽기 권한이 사라진 뒤 연결을 닫을 수 있었습니다. 그러나 사양은 단 하나의 즉시성을 가진 분산 회수 지점을 만들어내지 않았습니다. 운영자가 반드시 테스트해야 하는 세션 경계를 밝혔을 뿐입니다.

순서도 중요했습니다. 클라이언트가SETACL과MYRIGHTS를 파이프라인으로 보내면, 서버는 응답을 계산하기 전에 수정을 완료해야 했습니다. 프로토콜은 한 연결의 증거에 순서를 부여할 수 있었지만, 다른 세션이 무엇을 캐시했는지, 사람이 사용하는 클라이언트가 무엇을 표시할지 증명할 수는 없었습니다.

목록 자체가 권한을 노출했다

ACL은 메시지 본문을 전혀 담지 않았어도 민감했습니다. 어떤 사서함이 존재하는지, 어떤 사용자나 그룹이 존재하는지, 누가 그들을 관리하는지 드러낼 수 있었습니다. RFC 2086은 이미 권한 없는GETACL이 제한된 사서함을 노출해서는 안 된다고 경고했습니다. RFC 4314는 조회자에게 나열 권한이 없을 때 존재하지 않는 사서함에 대한 응답처럼 보이도록 응답을 요구했습니다.

이후 RFC는 읽기 권한만으로 ACL을 열람할 수 있다고 보는 관점도 거부했습니다. 목록 안의 식별자들 자체가 독립적인 보안 정보였습니다. 그리고 이 확장은 그 정보를 암호화하지 않았습니다. STARTTLS, 인증 과정의 개인정보 보호 협상, 또는 다른 보호 메커니즘이 없으면 ACL 데이터는 평문으로 전송되었습니다.

따라서 권한 부여와 기밀성은 별개로 남았습니다. 누가 사서함을 읽을 수 있는지에 대한 올바른 답변이, 그 답변 자체가 전송 중에 비밀로 유지된다는 보장은 아니었습니다.

자기 자신의 로컬적 잔여를 인정한 표준

RFC 4314는 자신의 한계를 나열했습니다. 신원을 결합하는 방법은 구현 정의로 남았습니다. 사용자, 그룹, 특수 식별자가 하나의 이름 공간에 공존했습니다. 친화적인 인터페이스가 서버의 로컬 모델을 항상 설명할 수는 없었습니다. 파일시스템에서 익숙한 소유권 변경 작업은 없었습니다.

그럼에도 이 문서는 하위 호환 개정을 가치 있는 것으로 평가했습니다. RFC 2086이 이미 여러 구현에 배포되어 있었기 때문입니다. 이후RFC 9051이 IMAP4rev2를 정의하고, 별도 명시가 없는 한 등록된 IMAP4rev1 확장을 일반적으로 계속 사용할 수 있도록 했습니다. 이는 프로토콜 표면의 연속성이지, 모든 현재 메일 서비스가 ACL이나 마이너스 권한을 구현한다는 증거가 아닙니다.

지속 가능한 결과는 더 좁습니다. IMAP는 하나의 규칙 목록을 모든 메일 서버의 주권자로 만들지 않았습니다. 대신 클라이언트가 선언된 항목, 부여 가능한 작업, 실효적 권한을 구분할 수 있을 만큼의 질문을 표준화하면서, 신원 그래프와 최종 판단은 집행하는 시스템에 책임을 남겼습니다.

출처