나는 그것을 unshare로컬 프로세스에 마운트하는 것과 같은 작업을 수행하는 데 사용합니다.루트 액세스가 필요하지 않습니다,예를 들어:
unshare -mr bash mount --bind a b
(예, 이것은 약간 어리석은 것 같습니다. 실제 사용 사례에서는 unshare바인드 마운트를 수행하는 bash 스크립트를 실행하고 있습니다. 여기서는 해당 작업을 수행하지 않으므로 더 작은 예입니다.)
그러나 설치를 반복하려고 하면 실패합니다.
ryan@DevPC-LX ~/stuff/util-linux master $ unshare -mr mount -o loop x.img a
mount: no permission to look at /dev/loop<N>
:/
mknod가짜 루프 장치를 만들고(루트가 아닌 사용자는 얻을 수 없는 권한이 필요함) 수동으로 실행하고 losetup(여전히 루트 권한이 필요함) 작동하지 않는 여러 가지 작업을 시도했습니다 .
물론 그렇게 할 수도 있지만 chown myuser /dev/loop*, 심각한 보안 문제가 될 수 있을 것 같습니다.
또한 guestmount내 사용 사례에 비해 너무 느리고 fuseext2쓰기 모드에서 데이터 손실 가능성에 대한 경고가 표시됩니다(또한 너무 느립니다).
이를 수행할 수 있는 방법이 있습니까? 있어요?
답변1
분명히 이해한 바와 같이 루프 설치 생성은 두 단계로 구성됩니다.
- 루프 장비 설정
- 설치하다
물론 myuser /dev/loop* 를 chown할 수도 있지만 이는 주요 보안 문제가 될 수 있는 것 같습니다.
나는 이것이 적절한 루프 장치의 생성을 허용할 것이라고 믿습니다(액세스 권한을 부여함으로써 /dev/loopcontrol). 루프 장치의 보기에 영향을 줄 수 있는 일종의 네임스페이스가 있는지 궁금합니다. 이렇게 하면 이 작업을 보다 안전하게 수행할 수 있습니다.
2단계는 아직 시도할 수 없습니다. 사용자 네임스페이스를 사용하면 사용자가 새 마운트를 생성할 수 있는 새 마운트 네임스페이스를 생성할 수 있지만 매우 제한적입니다.CAP_SYS_ADMIN 초기 네임스페이스에서블록 장치를 여전히 설치해야 합니다. user_namespaces(7)말했듯이...
그러나 블록 기반 파일 시스템 마운트는 초기 사용자 네임스페이스에 CAP_SYS_ADMIN을 보유하는 프로세스에 의해서만 수행될 수 있습니다.
루프 장치는 파일 기반 블록 장치이므로 여전히 사용할 수 없습니다. 이는 안타까운 일이며 안전하게 작업할 수 있는 방법이 있어야 한다고 생각합니다. 하지만 내 생각엔 여기에는 복잡한 문제가 많이 있는 것 같다(특히 setuid) 이것이 아직 구현되지 않은 이유입니다.
내가 이해한 바에 따르면, 실제로 할 수 있는 일은 문제를 해결하는 것뿐입니다. 아마도 이미지에서 파일을 추출한 다음(최악의 상황이 발생하고 특정 형식을 직접 처리할 수 있는 도구가 없는 경우 임시 가상 머신에 설치하여 이를 수행할 수 있음) 결과 디렉토리를 바인드 마운트할 수 있습니다.
답변2
공유 해제를 실행하려면 별도의 설치 공간을 생성할 수 있는 루트 권한이 있어야 합니다.
나는 당신이 원하는 것을하는 것처럼 보이는 이것을 시도했습니다 (제 생각에는) :
Ishtar:> mkdir -p /tmp/unshare/home
Ishtar:> cd /tmp/unshare
Ishtar:/tmp/unshare> sudo unshare -m /bin/bash
Ishtar:/tmp/unshare# mount --rbind /home/packages /tmp/unshare/home
Ishtar:/tmp/unshare# tty
/dev/pts/4
Ishtar:/tmp/unshare# # ls home
BUILD@ RPMS@ build/ linux@ sources/ tmp/
BUILDROOT@ SOURCES@ buildroot/ logs/ specs/
OSbuild/ SPECS@ config-scripts/ perlsrc/ srpms/
OTHER/ SRPMS@ debug@ rpms/ sysvinit-288.spec
따라서 위의 프로세스는 '/home/packages @ /tmp/unshare/home.dll'을 설치했습니다.
다른 tty 창에서 모든 사용자에 대해 /tmp/unshare/home에 무엇이 있는지 확인할 수 있습니다.
Ishtar:/> tty
/dev/pts/5
Ishtar:/> ll /tmp/unshare/home
total 0
Ishtar:/> cd tmp/unshare
Ishtar:/tmp/unshare> sudo
Ishtar:/tmp/unshare# ls home
Ishtar:/tmp/unshare# ll home
total 0
# create file in original "bound" dir from 1st usr above:
Ishtar:/tmp/unshare# touch /home/packages/PACKAGES.DIR
Ishtar:/tmp/unshare# ll home #home still empty
total 0
Ishtar:/> tty
/dev/pts/5
# now on other user again
Ishtar:/tmp/unshare# tty
/dev/pts/4
Ishtar:/tmp/unshare# ls home
BUILD@ RPMS@ buildroot/ perlsrc/ sysvinit-288.spec
BUILDROOT@ SOURCES@ config-scripts/ rpms/ tmp/
OSbuild/ SPECS@ debug@ sources/
OTHER/ SRPMS@ linux@ specs/
PACKAGES.DIR build/ logs/ srpms/
#^^^ see PACKAGES.DIR appear (as created in original dir by another
# user
"pts/4"에 사용자를 위해 "개인 디렉토리"가 마운트되면 프로그램을 실행할 UID로 변경할 수 있습니다.
Ishtar:/tmp/unshare# su astara
Ishtar:/tmp/unshare> whoami
astara
Ishtar:/tmp/unshare> ls home/PACK*
home/PACKAGES.DIR
권한이 없는 사용자에 대한 마운트는 여전히 존재합니다.
저장하기 위해 스크립트 파일에 "su to other user"를 넣은 다음 "unmount /tmp/unshare/home"을 넣었습니다(su OTHERUSER가 종료되면 다시 루트가 되어 개인 공간을 마운트 해제하기 때문입니다). 그런 다음 종료할 수 있습니다.
이것이 당신이 원하는 것에 가깝습니까? -- 하위 환경을 설정한 다음 하위 환경을 실행하려면 "root"를 사용해야 하며, 루트만 새 마운트 네임스페이스에 생성된 마운트에 액세스할 수 있습니다.
(업데이트) 그런데 - unshare에는 루트 또는 대문자를 사용하여 새 네임스페이스에서 옵션 설정을 특별히 허용하는 --map-root-user가 있다는 것을 확인했습니다. 맨페이지에는 (이 스위치에 대해) 다음과 같이 나와 있습니다.
....This makes it possible to conveniently
gain capabilities needed to manage various aspects of the newly
created namespaces (such as configuring interfaces in the net-
work namespace or mounting filesystems in the mount namespace)
even when run unprivileged.
이를 통해 루트가 필요 없이(또는 매뉴얼 페이지에 나와 있는 대로) 개발 루프를 관리할 수 있습니다. CAP_SYS_ADMIN은 아마도 이 작업을 수행하는 데 필요한 상한값일 것입니다.