요약

  • draft-ietf-nfsv4-internationalization-17은 NFSv4 이름에 대한 상이한 동작을 인정합니다: 불투명 옥텟, 유니코드 등가, 정규화, 대소문자 규칙. 일반적으로 클라이언트는 서버가 채택한 전체 동등성 관계를 알아낼 수 없습니다.
  • 백업, 복제, 페일오버 또는 마이그레이션에 앞서 운영자는 전송된 바이트, 반환된 이름, 환경, 충돌 테스트, 관찰된 기능, 남은 불확실성을 담은 네임스페이스 등가성 영수증을 발행해야 합니다.

파일은 열렸지만 규칙은 여전히 숨겨져 있다

특정 악센트 문자를 표현하는 유니코드 방식은 하나가 아닙니다. 한 애플리케이션은 미리 조합된 문자를 보낼 수 있고, 다른 애플리케이션은 기본 문자 뒤에 결합 부호를 붙일 수 있습니다. 화면에서는 이름이 같아 보입니다. 옥텟 단위로 비교하는 구현체에게는 서로 다른 시퀀스입니다.

두 형태가 같은 파일을 연다면, 어딘가에서 등가가 발생한 것입니다. 서버가 입력을 정규화했을 수 있습니다. 원래 형태를 보존하면서 형태에 민감하지 않게 비교했을 수도 있습니다. 기반 파일 시스템이 결정을 내렸을 수 있습니다. 로컬 옵션이 대소문자를 변경했을 가능성도 있습니다. 긍정적인 응답은 이 설명들 중 어느 것이 유효한지 알려주지 않습니다.

NFSv4 국제화 초안의 제17판은 IETF 최후 통지(Last Call) 의견을 반영하여 2026년 9월 11일에 발행되었습니다. 이 문서는 Standards Track에서 활성 상태이며 IESG에 회부되었습니다. 아직 인터넷 초안(Internet-Draft)입니다: RFC가 아니며, 어떤 제품이 서술된 동작을 구현했다는 증거도 아닙니다.

문서의 역사가 핵심입니다. 셰퍼드(shepherd) 보고서는 NFSv4.1의 국제화 규정이 계획대로 구현되지 않았다고 밝힙니다. 언급된 주요 구현체들은 널리 NFSv4.0 방식, 즉 UTF-8을 인식하지 않는 접근을 채택했고, 인식하는 기능은 제한적이며 실험적 수준에 머물렀습니다. 따라서 이 개정은 현실을 기반으로 합니다. 상호 운용성은 이전 문서가 기록한 의도가 아니라 시스템이 실제로 수행하는 비교에 달려 있습니다.

이름은 불투명 시퀀스일 수 있다

UTF-8 비인식 체계에서 각 컴포넌트는 불투명한 옥텟 문자열입니다. 비교는 정확해야 합니다. 이 선택은 오래된 인코딩으로 생성된 이름과 유효한 UTF-8을 형성하지 않는 바이트를 허용합니다. 동시에 문자 자체가 결정에 참여하지 않으므로, 서버가 두 유니코드 형태 간의 정규 등가를 선언하는 것을 막습니다.

결과에는 자체적인 일관성이 있습니다. 원래 바이트가 우세하고 라이브러리 업데이트가 오래된 항목을 자동으로 병합하지 않습니다. 그러나 사람은 같은 보이는 텍스트를 다른 조합으로 입력하고 파일을 찾지 못할 수 있습니다. 인간의 동등성과 디렉터리의 동일성은 서로 다른 것이 됩니다.

UTF-8 인식 서버는 저장 전에 정규화하거나, 받은 철자를 보존하면서 정규적으로 등가인 형태를 검색에서 수용할 수 있습니다. 대소문자 차이를 매핑하거나 비교에서 동일하게 취급할 수도 있습니다. 구현, 파일 시스템, 구성이 함께 유효 정책을 형성합니다; 같은 제품의 두 익스포트가 서로 달라질 수 있습니다.

또한 "유니코드 대소문자"라는 단일 약속도 존재하지 않습니다. 매핑은 언어와 사용자 선호에 따라 달라질 수 있습니다. 초안에 따르면, 이 모든 선택을 전달하는 표준화 준비가 완료된 일반 메커니즘은 아직 없습니다. "유니코드 지원"이라는 라벨은 검증, 저장, 비교, 표현 중 어느 것인지 알려주지 않습니다.

기능이 등가성을 드러내지 않는다

fs_charset_cap속성은 한정된 정보를 제공합니다. 현재 텍스트에서 이것은 UTF-8 이름만 수용하는 동작을 신호합니다.FSCHARSET_CAP4_CONTAINS_NON_UTF8의 역사적 사용은 모호해졌으며; 초안은 서버에 보수를 제공하고 클라이언트에 이 플래그를 무시하도록 지시합니다. 속성이 지원되지 않으면, 비 UTF-8 이름으로 통제된 테스트가 수용 여부에 관한 무언가를 보여줄 수 있습니다.

이것은 정규화가 존재하는지, 어떤 유니코드 버전이 그것을 지시하는지, 어떤 대소문자 변형이 일치하는지 알아내지 못합니다. "이 입력은 유효한가?"라는 질문은 "어떤 입력들이 같은 이름인가?"라는 질문과 다릅니다. 하나의 기능 비트는 첫 번째 질문에 부분적으로만 답하며, 두 번째 질문에는 답하지 않습니다.

성공 배터리조차 계약을 닫지 못합니다. 각 쿼리는 하나의 지점을 측정합니다. 이후 버전에 추가된 문자, 언어적 예외, 또는 저장소의 특정 동작이 샘플에서 벗어날 수 있습니다. 공급업체 문서도 관찰과 분리되어야 합니다: 설명이 NFS 계층에서 멈추고 실제 비교는 그 아래에서 발생할 수 있습니다.

나열은 모든 등가성을 열거하는 것이 아니다

READDIR은 서버가 제시하는 철자를 반환합니다. 같은 파일 핸들에 도달하기 위해LOOKUP이 수용할 모든 철자를 반환하지 않습니다. 서버는 하나의 이름을 보존하고 다른 이름을 등가로 인식할 수 있습니다. 따라서 목록을 내려받아 클라이언트에서 비교하는 것이 반드시 서버의 의미론을 재현하지는 않습니다.

부정 캐시는 이 차이를 악화시킵니다. 클라이언트는 자신의 규칙에 따라 "존재하지 않음"을 저장하고, 서버가 등가성으로 해석할 이름을 계속 거부할 수 있습니다.READDIR의 어떤 항목도 로컬에서 일치해 보이지 않아LOOKUP을 건너뛰고, 발견되었을 객체를 놓칠 수도 있습니다. 초안은 클라이언트가 정규화에 대비하되 그 발생을 가정하지 않도록 요청합니다.

시간이 시나리오를 수정합니다. 정규 등가 클래스는 유니코드가 문자를 추가할 때 구성원을 얻을 수 있습니다. 초안은 저장 형태를 강제하는 대신 형태에 무관한 비교를 선호하는데, 부분적으로는 파일 이름이 오래 지속되기 때문입니다. 바이트를 보존하는 것은 여전히 필요하지만, 미래의 플랫폼이 그것을 같은 방식으로 판단할 것을 보장하지 않습니다.

마이그레이션은 이름을 판단하는 주체를 교체하는 것이다

마이그레이션 계획은 볼륨, 수량, 권한, 날짜, 해시를 측정합니다. 등가 관계를 빠뜨리는 경우가 많습니다. 목적지에 항목을 재생성할 때, 새로운 스택이 무엇을 수용하고 무엇을 병합할지 결정합니다.

원본이 두 시퀀스를 구별하고 목적지가 그것을 하나로 간주하면 충돌 또는 덮어쓰기가 발생합니다. 원본이 같은 항목에 대해 두 형태를 수용하고 목적지가 정확한 일치를 요구하면, 애플리케이션이 사용한 변형이 작동을 멈춥니다. 목적지가 역사적 바이트를 거부하면 백업이 콘텐츠를 보존하면서도 주소를 복원하지 못할 수 있습니다. 대소문자 규칙이 바뀌면 이전에 서로 다른 경로들이 경쟁하게 됩니다.

알려진 파일 몇 개를 여는 것은 위험이 가장 낮은 이름들을 선호합니다: 현재, 빈번, 오늘날의 라이브러리와 키보드에서 생성된 이름들. 이것은 상속된 자료, 희귀한 조합, 그리고 서버가 항상 조율해왔기 때문에 아무도 인지하지 못한 변형에는 도달하지 못합니다.

복원 시, 장애는 원본의 폐기 이후에 나타날 수 있습니다. 복제에서 침묵하는 병합이 수렴처럼 보일 수 있습니다. 페일오버에서 콘텐츠는 보조 노드에 있지만 프로그램은 그것을 부르는 방법을 잃습니다.

네임스페이스 등가성 영수증

영향력 있는 결정에는 다른 운영자가 검토할 수 있는 짧은 아티팩트가 필요합니다. 그것을 네임스페이스 등가성 영수증이라 부르겠습니다. 이것은 IETF 프로젝트의 요구사항이 아니라 편집적 거버넌스 제안입니다.

영수증은 NFS 버전, 서버 구현과 버전, 알려진 경우 파일 시스템, 익스포트와 마운트 옵션, 운영체제, 유니코드 라이브러리, 날짜를 식별합니다. 테스트된 각 컴포넌트는 정확한 바이트로 그리고 안전한 표시로 보존됩니다. 표시는 사람을 돕습니다; 바이트는 기록 도구가 증거 자체를 정규화하지 못하게 합니다.

코퍼스는 실제로 존재하는 이름으로 시작하고 위험 지향 쌍을 포함합니다: 조합형과 분해형, 관련 대소문자 변형, 상속된 비 UTF-8 바이트, 버전에 민감한 문자. 생성과 충돌은 격리된 영역에서 비파괴적으로 테스트됩니다.LOOKUP이 같은 파일 핸들을 반환하는지,READDIR이 무엇을 제시하는지, 생성이 수용되는지,fs_charset_cap이 무엇을 알리는지, 그리고 부정 캐시 없이 결과가 지속되는지가 기록됩니다.

원본과 목적지는 비교 가능한 시험을 수행해야 합니다. 각 항목은 관찰, 공급업체 주장, 아직 입증되지 않은 추론을 분리합니다. 충돌, 거부, 모호성에는 책임자와 처리 방식이 할당됩니다: 가역적 이름 변경, 이스케이프, 격리, 호환성 계층 또는 인지된 수용. 어떤 변형이든 원본이 종료된 후 원래 바이트, 새 이름, 콘텐츠 신원 사이의 맵을 보존합니다.

범위는 정확해야 합니다. 심볼릭 링크 콘텐츠는 다른 규칙 하에서 불투명합니다; 비 ASCII 도메인 이름은 U-label을 사용합니다; NFS의 문자열 유형은 균일하지 않습니다. 영수증은 "일반적인 유니코드"를 인증하지 않습니다. 특정 환경에서 관찰된 특정 관계를 기록합니다.

증거의 한계

RFC 6943은 식별자의 일관 없는 비교가 위양성, 위음성, 서비스 거부, 특정 시스템에서 권한 상승을 유발할 수 있음을 보여줍니다. 이것은 NFS의 사건 보고가 아니며, 초안도 그러한 주장을 하지 않습니다. 경로가 권한 부여, 실행 또는 기록 보존에 관여할 때 보안 검토에 이름 등가성을 포함할 충분한 이유입니다.

방어 가능한 결론은 좁습니다: 서버 측 네임스페이스가 특정 시점, 특정 구성 하에서 특정 바이트 시퀀스를 해석했다는 것. 이것은 보편적 문자 동일성, 이식 가능한 등가 관계, 다른 서버가 판단을 반복할 것이라는 약속을 확립하지 않습니다. 이름은 라벨처럼 보이지만, 분산된 실무에서는 정책의 결과이기도 합니다.

출처