화이트아웃 파일을 AUFS 형식에서 커널 오버레이 FS 형식으로 변환하려고 합니다. 이것필요확장 속성 trust.overlay.opaque = y를 사용하여 특정 디렉토리를 표시합니다. 불행하게도 FreeBSD는 적어도 기본적으로 사용자 및 시스템 네임스페이스에 대한 확장 속성만 지원하는 것 같습니다. 이 제한을 우회할 수 있는 방법이 있나요? 이것엑스트라 매뉴얼즉, 마운트할 수 있는 일부 파일 시스템은 신뢰할 수 있는 네임스페이스를 포함하여 다른 네임스페이스를 지원할 수 있지만 신뢰할 수 있는 네임스페이스의 사용을 허용하는 마운트할 수 있는 파일 시스템을 찾을 수 없습니다.
불행하게도 지원되는 FreeBSD 버전으로 업그레이드할 수 없습니다. 또한 KOFS에는 신뢰할 수 있는 네임스페이스 대신 사용자 네임스페이스에서 불투명 흰색 파일을 읽는 플래그가 있지만 여전히 tempfs 위에 KOFS를 구축하고 있습니다.지원하지 않음사용자 네임스페이스 확장 속성.
어떤 아이디어가 있나요?
답변1
핵심요약: 특정 사용 사례의 경우 시스템 네임스페이스를 사용해야 합니다.
FreeBSD의 extattr(9) 매뉴얼 페이지는 여기에서 약간 장황하게 설명되어 있지만 실제로 의미하는 바는 두 개의 표준 속성 네임스페이스(user 및 system)가 정의되어 있지만 파일 시스템 API는 단지 정수이기 때문에 기술적으로 다른 네임스페이스를 허용한다는 것입니다. Linux의 API도 비슷하게 개방되어 있지만 4개의 표준 네임스페이스가 정의되어 있습니다. 하지만 다른 네임스페이스는 이름의 문자열 접두사이므로 기술적으로 허용됩니다.
두 경우 모두 실제로 중요한 것은 사용 중인 파일 시스템이 실제로 어떤 속성과 의미를 지원하는지입니다. 이미 알고 있듯이 FreeBSD의 tmpfs는 시스템 속성만 지원합니다.
Linux "user"네임스페이스는 FreeBSD 사용자 네임스페이스( EXTATTR_NAMESPACE_USER또는 1)에 직접 매핑됩니다. 허용되는 것과 허용되지 않는 것에는 약간의 미묘한 차이가 있을 수 있습니다. 이는 파일 모드 비트를 기반으로 POSIX 의미 체계를 따르기를 기대하는 사람들에게는 놀랄 수 있지만 권한이 없는 사용자는 일반적으로 자신의 파일 사용자 속성에서 작업할 것으로 예상할 수 있습니다.
Linux의 "security", "system"및 네임스페이스는 FreeBSD의 시스템 네임스페이스( , 또는 2) "trusted"에 어느 정도 매핑됩니다 . EXTATTR_NAMESPACE_SYSTEM여기에 액세스하려면 높은 권한이 필요합니다. Linux에서는 특정 네임스페이스와 속성 이름에 따라 다르지만 CAP_SYS_ADMINFreeBSD에서는 이 기능이 좋은 시작점이 됩니다 PRIV_VFS_EXTATTR_SYSTEM.
Linux에 하나가 아닌 세 개의 시스템 네임스페이스가 있는 정확한 이유는 시간이 지나서 잊혀졌을 수도 있지만 커널 개발자는 이름 충돌을 피하기 위해 다양한 시스템 구성 요소에 접두사를 제공하고 싶었고 이는 가장 깔끔한 접근 방식으로 간주되었습니다. (커널이 아닌 시스템 속성은 "trusted"당시에는 여전히 중요하지 않은 것처럼 보입니다.)
완전성을 위해 MacOS에는 확장 속성도 있습니다. API는 Linux와 매우 유사하지만 네임스페이스 측면에서 약간 혼란스럽습니다. 속성에는 예를 들어 접두사가 있는 경향이 있지만 "com.apple."이는 이름 충돌을 피하기 위한 규칙일 뿐이며 커널은 이에 거의 주의를 기울이지 않습니다. 일반적으로 이러한 이름은 추가 옵션을 제공하지 않는 한 사용자 네임스페이스에 있습니다. XATTR_SHOWCOMPRESSION이 경우 다른 이름이 나타나며 그 중 일부는 루트에서도 액세스할 수 없습니다. 그동안 솔라리스에 대한 언급은 적을수록 좋습니다.