내 "일반" 시스템과 별도의 마운트 및 사용자 네임스페이스에 tmpfs를 설치할 때 모든 사용자/그룹 ID를 사용할 수 있을 것으로 예상됩니다.
tmpfs는 해당 마운트 네임스페이스에만 존재하므로 매핑 ID가 필요하지 않습니다(단, /etc/sub{g,u}id를 설정했습니다).
그러나 일어나는 일은 다음과 같습니다.
me $ mkdir tmp
me $ unshare -Urm
root $ mount -t tmpfs none tmp
root $ cd tmp
root $ touch asdf
root $ chown 3:3 asdf
chown: changing ownership of 'asdf': Invalid argument
이유를 알 수 없습니다. 누군가 이것에 대해 밝힐 수 있습니까?
복사-붙여넣기 테스트의 경우 unshare -Urm
:
mkdir tmp
mount -t tmpfs none tmp
cd tmp
touch asdf
chown 3:3 asdf
답변1
특정 사용자 네임스페이스의 경우 네임스페이스 내에 매핑되지 않은 특정 UID 또는 GID를 가진 모든 프로세스(이는 실행 중인 실제 초기 루트 사용자에게도 영향을 미칠 수 있음 unshare -Urnm
)는 시스템 호출에 따라 EPERM 또는 EINVAL 오류를 수신합니다. : 어떤 방식으로든 해당 UID에 영향을 미치는 작업(예: 프로세스 또는 파일)을 수행하려고 합니다. 에 설명되어 있지만 user_namespace(7)
설명이 상당히 복잡합니다.
해당 UID/GID 값을 읽으려고 시도합니다. EINVAL이 발생하지 않으면 오버플로된 UID/GID가 검색됩니다. 일반적으로 아무도, 그룹도 검색되지 않습니다. 자세한 내용을 참조하세요.매핑되지 않은 사용자 및 그룹 IDuser_namespace(7)
맨 페이지 에서 .
여러 개의 UID를 포함시키는 유일한 방법은 권한이 있는 도우미를 사용하는 것입니다. podman
.command 와 같이 일반 사용자로 실행되도록 설계된 도구에도 종속되는 공통 도우미가 한 쌍 있습니다.newuidmap
그리고newgidmap
사용자 자격 증명 확인/etc/subuid
그리고/etc/subgid
. 이러한 파일의 항목은 일반적으로 사용자 계정이 생성될 때 추가되지만 추가 요구 사항을 충족하기 위해 수정할 수 있습니다.
사용자가 사용자 네임스페이스를 루트로 일방적으로 변경하고 상위(예: 호스트) 사용자 네임스페이스에 영향을 미칠 수 있는 경우 해당 사용자는 루트 사용자의 권한을 갖게 됩니다. 그러나 실제로는 그렇지 않습니다. 도우미 사용의 의도된 용도는 이 사용자에 대한 UID-GID 범위(0-65534뿐만 아니라 0-4294967294의 하위 범위)를 예약하는 것입니다. 책임을 위해 매핑은 사용자마다 달라야 합니다(그러나 필수는 아닙니다).