none:nogroup을 사용하여 디렉터리 소유권을 변경하는 방법은 무엇입니까? 내가 시도하는 모든 것은 "작업이 허용되지 않음"으로 끝납니다.
cat /etc/debian_version
10.2
root@torrent:/srv# chown -R rtorrent:rtorrent rtorrent
chown: cannot read directory 'rtorrent/.local/share': Permission denied
chown: changing ownership of 'rtorrent/.local': Operation not permitted
chown: changing ownership of 'rtorrent/.bash_history': Operation not permitted
chown: changing ownership of 'rtorrent/session/rtorrent.dht_cache': Operation not permitted
chown: changing ownership of 'rtorrent/session': Operation not permitted
chown: changing ownership of 'rtorrent/.rtorrent.rc': Operation not permitted
chown: changing ownership of 'rtorrent/download': Operation not permitted
chown: changing ownership of 'rtorrent/watch': Operation not permitted
chown: changing ownership of 'rtorrent': Operation not permitted
rm -r download/
rm: cannot remove 'download/': Permission denied
root@torrent:/srv/rtorrent# ls -al
total 32
drwxr-xr-x 6 nobody nogroup 4096 Jan 24 18:16 .
drwxr-xr-x 3 root root 4096 Jan 24 16:46 ..
-rw------- 1 nobody nogroup 47 Jan 24 18:16 .bash_history
drwxr-xr-x 3 nobody nogroup 4096 Jan 24 18:15 .local
-rw-r--r-- 1 nobody nogroup 3224 Jan 24 18:16 .rtorrent.rc
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 16:46 download
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 18:21 session
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 16:46 watch
답변1
귀하의 컨테이너는 다음을 기반으로 구축된 사용자(루팅되지 않은) 컨테이너로 실행 중인 것으로 보입니다.사용자 네임스페이스.
작동하려면 사용자 컨테이너에 연결된UID/지드번역 호스트에 매핑UID/지드컨테이너에UID/지드. 이들의 전체 호스트 범위는 2^32입니다(실제로는 0부터 시작).뿌리사용자). 이것으로부터 컨테이너의 할당 범위는 일반적으로 2^16으로 유지되는 것으로 보입니다(이것은 역사적으로 호환 가능).UID범위).
모든 호스트UID범위가 다음으로 변환되지 않습니다.UID컨테이너는 다음과 같이 나타납니다.아무도(각기:그룹 없음~을 위한지드) 사용자 컨테이너 내부. 이 컨테이너와 마찬가지로뿌리그러한 제품에 대한 권리는 없습니다UID, 변경할 수 없으며 일반 사용자로 실행하는 것처럼 작업이 실패합니다.
다음은 문제를 설명하는 Proxmox의 링크입니다.
https://pve.proxmox.com/wiki/Unprivileged_LXC_containers
그러나 다음 조건이 충족되는 한 모든 파일과 디렉터리가 "nobody"(uid 65534)로 매핑된다는 사실을 곧 깨닫게 될 것입니다.
- 제한된 권한을 설정하지 않았습니다(그룹/사용자만 파일을 읽거나 디렉터리에 액세스할 수 있음).
- 모든 파일이 높은 매핑(100000+) uid로 생성되므로 특정 uid/gid를 사용하여 파일을 작성하고 싶지 않습니다.
이러한 범위를 변환하도록 특별히 설계된 도구가 있으므로 준비된 시스템 트리 레이아웃을 대상 컨테이너에 적합한 범위로 전송할 수 있습니다. 이러한 도구는 호스트 시스템에서 실행되어야 합니다(또는 적어도 "재귀" 컨테이너의 경우 컨테이너는 사용자 네임스페이스를 "생성"합니다). 예를 들어:
https://github.com/jirutka/uidmapshift
이것은 분명히 존재하지 않는 프로젝트 nsexec에서 uidmapshift를 다시 구현한 것입니다:
https://github.com/fcicq/nsexec
물론 올바른 목표를 계산하여 수동으로 수행할 수도 있습니다.UID:지드chown(호스트에서) 사용합니다 . 값과 간단한 매핑이 있으면 쉬울 것입니다. 다음은 실행 중인 사용자 LXC 컨테이너를 사용하는 예입니다.
컨테이너(라고 함)버스터-amd64):
user@buster-amd64:~$ ls -n test
-rw-r--r--. 1 65534 65534 0 Jan 24 21:09 test
root@buster-amd64:/home/user# chown user:user test
chown: changing ownership of 'test': Operation not permitted
호스트(동일한 파일 표시):
user@host:~$ ls -n ~/.local/share/lxc/buster-amd64/rootfs/home/user/test
-rw-r--r--. 1 1000 1000 0 Jan 24 22:09 /home/user/.local/share/lxc/buster-amd64/rootfs/home/user/test
다음 명령은 init 프로세스를 가져옵니다.PID(컨테이너에 1개가 있지만 여기서는PID컨테이너에서 실행되는 값(호스트 머신에 표시됨)(컨테이너의 다른 프로세스도 작동함):
user@host:~$ lxc-info -Hpn buster-amd64
22926
user@host:~$ cat /proc/22926/uid_map
0 1410720 65536
이 매핑은 LXC 구성에 이미 정의되어 있어야 합니다.
user@host:~$ grep lxc.idmap ~/.local/share/lxc/buster-amd64/config
lxc.idmap = u 0 1410720 65536
lxc.idmap = g 0 1410720 65536
사용자 컨테이너의 uid가 1000이고 파일/디렉토리가 해당 사용자에 속해야 하는 경우 새 호스트의 uid는 1410720 + 1000 = 1411720이어야 합니다.
콘솔에서는 이번에는 (진짜)뿌리사용자:
root@host:~# chown 1411720:1411720 ~user/.local/share/lxc/buster-amd64/rootfs/home/user/test
이는 컨테이너의 파일 시스템이 호스트 파일 시스템의 어딘가에 직접 마운트되지 않고(예: LVM 백업 저장소 또는 tmpfs를 사용하여 마운트) 따라서 액세스할 수 없는 경우 실행 중인 컨테이너에도 적용됩니다(선호되어야 함).
root@host:~# chown 1411720:1411720 /proc/22926/root/home/user/test
이제 컨테이너에서:
user@buster-amd64:~$ ls -n test
-rw-r--r--. 1 1000 1000 0 Jan 24 21:09 test
그리고 그것의뿌리파일이 올바른 위치에 있으므로 이제 사용자는 파일에 대한 권한을 가집니다.UID/지드매핑.
root@buster-amd64:~# chown root:root ~user/test
root@buster-amd64:~#
커널 측에서 다음과 같은 기능을 사용하는 작업이 진행 중입니다.시프트 파일 시스템아직형태 변경번들 마운트를 통해 이 변환을 수행하면 이러한 문제를 완화하는 데 도움이 됩니다.