LXD/LXC를 실행하고 권한이 없는 컨테이너 설정에서 Debian 12.1(6.1.0-11-amd64) security.idmap.isolated=true이 컨테이너 파일의 소유자/그룹을 업데이트하지 못하는 것 같습니다.
예는 다음과 같습니다.
# lxc launch images:debian/12 debian
(...)
# lxc config get debian volatile.idmap.base
296608
# lxc stop debian
Error: The instance is already stopped
# lxc config set debian security.idmap.isolated true
# lxc config get debian security.idmap.isolated
true
# lxc start debian
이제 컨테이너 볼륨의 파일을 나열하면 해당 파일이 모두 호스트 root사용자의 소유라는 것을 알 수 있습니다.
# ls -la /mnt/NVME1/lxd/containers/debian/rootfs/
total 24
drwxr-xr-x 1 root root 154 Sep 5 06:28 .
d--x------ 1 296608 root 78 Sep 5 15:59 ..
lrwxrwxrwx 1 root root 7 Sep 5 06:25 bin -> usr/bin
drwxr-xr-x 1 root root 0 Jul 14 17:00 boot
drwxr-xr-x 1 root root 0 Sep 5 06:28 dev
drwxr-xr-x 1 root root 1570 Sep 5 06:28 etc
여러 버전의 LXD/LXC를 사용해 보았습니다. 이는 5.0.2 from apt과 4.0 및 5.17(최신) 모두에서 발생합니다 snap.
흥미롭게도 또 다른 Debian 10(4.19.0-25-amd64)이 실행 중이고 이전 LXD 4가 snap예상대로 작동합니다.
# ls -la /mnt/NVME1/lxd/containers/debian/rootfs/
total 0
drwxr-xr-x 1 1065536 1065536 138 Oct 29 2020 .
d--x------ 1 1065536 root 78 Oct 14 2020 ..
drwxr-xr-x 1 1065536 1065536 1328 Jul 24 19:07 bin
drwxr-xr-x 1 1065536 1065536 0 Sep 19 2020 boot
drwxr-xr-x 1 1065536 1065536 0 Oct 14 2020 dev
drwxr-xr-x 1 1065536 1065536 1716 Jul 24 19:08 etc
이 시스템에서 볼 수 있듯이 모든 파일은 1065536:1065536.
업데이트:
나는 두 기계 모두에서 지도를 탐색하려고 시도했고 lxc config show debian다음을 보았습니다.
Debian 10을 실행하는 머신:
security.idmap.isolated: "true"
(...)
volatile.idmap.base: "1065536"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'
volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'
Debian 12를 실행하는 머신:
security.idmap.isolated: "true"
(...)
volatile.idmap.base: "231072"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":231072,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":231072,"Nsid":0,"Maprange":65536}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":231072,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":231072,"Nsid":0,"Maprange":65536}]'
volatile.last_state.idmap: '[]'
업데이트:
나는 또한 새로 설치를 시도했다Debian 11(5.10.0-25-amd64) 예상대로 작동합니다.:
root@vm-debian-11-cli:~# ls -la /mnt/NVME1/lxd/containers/debian/rootfs/
total 24
drwxr-xr-x 1 1065536 1065536 154 Sep 6 06:28 .
d--x------ 1 1065536 root 78 Sep 6 15:31 ..
lrwxrwxrwx 1 1065536 1065536 7 Sep 6 06:25 bin -> usr/bin
drwxr-xr-x 1 1065536 1065536 0 Jul 14 17:00 boot
drwxr-xr-x 1 1065536 1065536 0 Sep 6 06:28 dev
drwxr-xr-x 1 1065536 1065536 1570 Sep 6 06:28 etc
왜 채워지지 않았나요 volatile.last_state.idmap: '[]'? 데비안 10과 11 모두에서 작동하는 것처럼 이것은 분명히 새로운 커널 및/또는 그 구성과 관련이 있을 수 있습니다.
어떻게 해결할 수 있나요? 감사합니다.
답변1
분명히 이것은 설계상 최신 커널의 기능입니다. 다음은 LXC의 관리자인 Stéphane Graber의 좋은 설명입니다.
VFS idmap을 사용할 수 있기 전에는 LXD가 디스크에 있는 모든 단일 파일의 소유자를 수동으로 다시 쓰도록 하여 파일 소유권 문제를 해결해야 했습니다. 이것이 여러분이 이전 커널에서 보여주고 있는 것입니다.
최신 커널에서는 커널이 디스크에 대한 권한을 이동하지 않은 상태로 유지하고 커널 내에서 이동하여 컨테이너 내부에서 소유권이 올바르게 보이도록 할 수 있으므로 더 이상 필요하지 않습니다.
위에 표시된 내용은 VFS idmap을 지원하는 커널에서 완벽하게 작동하는 설정처럼 보입니다.
실제로 호스트 컴퓨터에서 이것을 구성할 수 있습니다.
root@vm-debian-12-cli:~# lxc info | grep 'shift\|idmap'
- storage_shifted
idmapped_mounts: "true"
shiftfs: "false"
idmapped_mounts_v2: "true"
그리고 컨테이너 내부의 루트 마운트 지점도 idmapped(마지막 줄)로 표시됩니다.
root@debian:~# cat /proc/self/uid_map
0 231072 65536
root@debian:~# cat /proc/self/gid_map
0 231072 65536
root@debian:~# cat /proc/self/mountinfo
490 460 0:24 /@rootfs/mnt/NVME1/lxd/containers/debian/rootfs / rw,relatime,idmapped shared:251 master:1 - btrfs /dev/sda1 rw,space_cache=v2,user_subvol_rm_allowed,subvolid=259,subvol=/@rootfs/mnt/NVME1/lxd/containers/debian
이를 비활성화하려면 다음을 수행하십시오.
systemd 단위에 재정의를 추가하여 LXD에 전달할 수 있는 환경 변수가 있습니다. LXD_IDMAPPED_MOUNTS_DISABLE=1
그러나 Mr. Graber에 따르면 우리는 그렇게 해서는 안 됩니다:
좋습니다. 귀하의 시스템은 현재 가능한 가장 낮은 오버헤드로 완벽하게 정상적으로 작동하고 있으므로 걱정할 필요가 없습니다.
이전의 시작 전 이동 방법은 매우 느리고 매우 위험했습니다. 특정 비트의 메타데이터(ACL, xattr 등)가 충돌하거나 이동하지 못하면 컨테이너에 보안 문제가 발생할 수 있기 때문입니다. 컨테이너의 모든 단일 파일이 수정된 것처럼 보이게 만들어 잠재적으로 GB 단위의 데이터가 중복될 수 있기 때문에 CoW 파일 시스템에도 끔찍한 일이었습니다.
Shiftfs(우분투 특정 해킹)와 이제 적절한 VFS idmap 이동을 사용하면 커널이 모든 파일 시스템 작업에서 역방향 uidmap/gidmap을 idmapped로 표시된 마운트에 적용하게 됩니다. 이는 수행하기 매우 간단한 작업이며, 컨테이너 맵에 대한 동적 변경을 허용하고(격리된 경우 매우 유용함) 컨테이너 간에 데이터를 공유할 수 있으며 uid/gid(ioctl, xattr, acl 등)를 보유할 수 있는 모든 것을 적절하게 지원합니다. 무언가를 놓칠 위험을 없애는 것입니다.