Moby: 루트가 아닌 사용자로 볼륨을 마운트하는 기능 추가

볼륨을 바인드 마운트하기 전에 호스트 측에서 chown 하면 작동합니다.
이 경우 다음을 수행할 수 있습니다.

mkdir /tmp/www
chown 101:101 /tmp/www
docker run -v /tmp/www:/var/www ubuntu stat -c "%U %G" /var/www

( 101:101 가 컨테이너에 있는 www-data 사용자의 UID:GID라고 가정합니다.)

또 다른 가능성은 bind-mount를 수행한 다음 컨테이너 내부에서 chown 를 수행하는 것입니다.

@mingfang chown이 작동하지 않습니까?

이에 대한 바로 가기가 있으면 유용할 것입니다. 볼륨에 대한 권한을 설정하는 run 스크립트를 작성하는 경우가 종종 있습니다.

https://github.com/orchardup/docker-redis/blob/07b65befbd69d9118e6c089e8616d48fe76232fd/run

chown 에 대한 권한이 없으면 어떻게 합니까?

chown 볼륨의 도우미 스크립트가 이 문제를 해결합니까? 이 스크립트는 Dockerfile의 ENTRYPOINT 수 있습니다.

아니오라고 말할 수 있습니까 - 사용자가 다음을 수행하는 도우미 스크립트를 추가하도록

#!/bin/sh
chown -R redis:redis /var/lib/redis
exec sudo -u redis /usr/bin/redis-server

(예를 들어 @bfirsh 에게 감사드립니다)

꽤 끔찍합니다.

이는 컨테이너가 의도한 redis 사용자로 실행되지 않고 루트로 시작되어야 함을 의미합니다. ( @aldanor 가 언급했듯이)

사용자가 다음과 같은 작업을 수행할 수 없음을 의미합니다.

docker run -v /home/user/.app_cfg/ -u user application_container application :(

작동하게 하는 _하나의_ 방법이 있지만 Dockerfile 내에서 미리 준비해야 합니다.

RUN mkdir -p /var/lib/redis ; chown -R redis:redis /var/lib/redis
VOLUME ["/var/lib/redis"]
ENTRYPOINT ["usr/bin/redis-server"]
USER redis

(나는 이 예제를 테스트하지 않았으며, 크롬 컨테이너에서 작업하고 있으며 _separate_ X11 컨테이너에 표시됩니다. .... )

물론 그 방법은 바인딩이 아닌 직접 새 볼륨에 대해서만 작동합니다.
마운트 또는 볼륨-볼륨에서. ;)

또한 volumes-from 를 사용하는 여러 컨테이너는 동일한 사용자에 대해 다른 uid/gid를 가지므로 항목도 복잡해집니다.

@SvenDowideit @tianon 그 방법도 작동하지 않습니다. 전체 예:

FROM ubuntu
RUN groupadd -r redis    -g 433 && \
useradd -u 431 -r -g redis -d /app -s /sbin/nologin -c "Docker image user" redis 
RUN mkdir -p /var/lib/redis
RUN echo "thing" > /var/lib/redis/thing.txt
RUN chown -R redis:redis /var/lib/redis
VOLUME ["/var/lib/redis"]
USER redis
CMD /bin/ls -lah /var/lib/redis

-v 볼륨이 있거나 없는 두 번의 실행:

bash-3.2$ docker run -v `pwd`:/var/lib/redis voltest 
total 8.0K
drwxr-xr-x  1 root root  102 Aug  7 21:30 .
drwxr-xr-x 28 root root 4.0K Aug  7 21:26 ..
-rw-r--r--  1 root root  312 Aug  7 21:30 Dockerfile
bash-3.2$ docker run  voltest 
total 12K
drwxr-xr-x  2 redis redis 4.0K Aug  7 21:30 .
drwxr-xr-x 28 root  root  4.0K Aug  7 21:26 ..
-rw-r--r--  1 redis redis    6 Aug  7 21:26 thing.txt
bash-3.2$ 

우리는 이것으로 해결될 문제에 부딪히고 있습니다(제 생각에는). 개발자의 홈 디렉토리에 대한 NFS 공유가 있습니다. 개발자는 /home/dev/git/project 를 Docker에 마운트하고 싶지만 루트 스쿼시가 활성화되어 있기 때문에 마운트할 수 없습니다.

이것은 루트가 /home/dev/git/project 에 액세스하는 것을 금지하므로 /home/dev/git/project 를 마운트하는 도커를 실행하려고 하면 lstat permission denied 오류가 발생합니다.

@frankamp 이것은 도커의 현재 기본 설정이 도커가 제어할 수 없는 호스트 항목을 수정하지 않는 것이기 때문입니다.

-v pwd`:/var/lib/reds`가 "VOLUME" 정의를 덮어씁니다.
그러나 두 번째 실행에서는 /var/lib/docker에 생성된 도커 제어 볼륨을 사용하고 있습니다. 컨테이너가 시작되면 도커는 이미지에서 볼륨으로 데이터를 복사한 다음 볼륨이 지정된 디렉토리의 uid:gid 를 사용하여 볼륨을 chowning합니다.

여기에서 수행할 수 있는 작업이 많지 않으며 불행히도 바인드 마운트는 (내가 말할 수 있는 한) 다른 uid/gid로 마운트하는 것을 지원하지 않습니다.

이에 대한 나의 해결책은 위에서 SvenDowideit가 수행한 작업(새 사용자 생성 및 dockerfile에서 전면 chown)을 수행하는 것이지만 호스트 볼륨을 마운트하는 대신 데이터 전용 컨테이너를 사용하고 마운트하려는 호스트 볼륨을 복사합니다. tar cf - . | docker run -i --volumes-from app_data app tar xvf - -C /data 가 있는 컨테이너 https://github.com/docker/docker/pull/13171 이 병합되면(그리고 docker cp 는 양방향으로 작동함) 이것은 조금 더 쉬워지지만 아마도 -v host_dir:container_dir 의 대안이 될 수 있습니다. -vc host_dir:container_dir , (볼륨 복사의 경우 vc), 여기서 host_dir의 내용은 데이터 컨테이너에 복사됩니다. 복사된 파일이 컨테이너 사용자의 권한을 상속받는 이유/방법을 이해할 수는 없지만, 내가 말할 수 있는 것은 이것이 제가 생각해낸 유일한 합리적인 솔루션으로 이식성을 파괴하지 않는 것입니다.

CL은 어떻습니까?

수정 사항이나 해결 방법이 있습니까? OpenShift에서 동일한 문제가 발생했습니다. 마운트된 폴더는 root:root 가 소유하고 미리 생성된 이미지는 작동하지 않습니다.

저도 해결 방법을 찾고 있습니다. 마운트된 모든 볼륨이 root 소유인 경우 root 이외의 다른 사용자로 Docker 컨테이너를 실행할 수 없습니다.

글쎄, 당신은 s6-overlay 를 시도 할 수 있습니다. 여기에는 이러한 종류의 문제를 해결하는 데 도움이 되도록 특별히 설계된 기능이 포함되어 있습니다.

@dreamcat4 : 포인터 주셔서 감사합니다. 소유권 및 권한 수정 은 흥미로운 해결 방법처럼 보이지만 작동하려면 Docker 컨테이너를 루트로 실행해야 하지 않을까요?

@brikis98 네 맞습니다. 그러나 s6-overlay에는 서버/데몬을 시작할 때 권한을 다시 삭제할 수 있는 또 다른 기능이 있습니다.

@dreamcat4 아, 그렇군요. 감사합니다.

컨테이너 내부와 외부에 동일한 uid/gid가 있으며 이것이 내가 얻는 것입니다.

nonroot$ ls -l .dotfiles/
ls: cannot access .dotfiles/byobu: Permission denied
ls: cannot access .dotfiles/config: Permission denied
ls: cannot access .dotfiles/docker: Permission denied
ls: cannot access .dotfiles/vim: Permission denied
ls: cannot access .dotfiles/bashrc: Permission denied
ls: cannot access .dotfiles/muse.yml: Permission denied
ls: cannot access .dotfiles/my.cnf: Permission denied
ls: cannot access .dotfiles/profile: Permission denied
total 0
-????????? ? ? ? ?            ? bashrc
d????????? ? ? ? ?            ? byobu
d????????? ? ? ? ?            ? config
d????????? ? ? ? ?            ? docker
-????????? ? ? ? ?            ? muse.yml
-????????? ? ? ? ?            ? my.cnf
-????????? ? ? ? ?            ? profile
d????????? ? ? ? ?            ? vim
nonroot$ ls -l .ssh
ls: cannot access .ssh/authorized_keys: Permission denied
total 0
-????????? ? ? ? ?            ? authorized_keys
nonroot$

@darkermatter 별도의 문제를 열어 주시겠습니까?

문제는 아니지만 여기에 관련되지 않습니까?

@darkermatter 이것은 버그 보고서가 아닌 기능 요청입니다. 귀하의 사례를 다른 사례와 혼합하면 토론을 따르기가 어렵고 귀하의 문제가 직접적인 관련이 없을 수도 있습니다.

@thaJeztah 음 , @frankamp 와 다른 사람들이 한 것처럼 Dockerfile 내에서 chmod 등을 실행한 후 어떤 일이 발생하는지 단순히 시연했습니다. 버그 보고서로 제출할 것이지만 이 토론과 관련이 있습니다.

@ebuchman이 제안한 것과 유사하게 호스트 볼륨을 복사하지 않고 먼저 데이터 전용 컨테이너를 생성할 수 있습니다.
chown 1000:1000 /volume-mount 시작 시 루트로.
예: docker compose v2 구문

version: '2'
services:
  my-beautiful-service:
    ...
    depends_on:
      - data-container
    volumes_from:
      - data-container

  data-container:
    image: same_base_OS_as_my-beautiful-service
    volumes:
      - /volume-mount
    command: "chown 1000:1000 /volume-mount"

이렇게 하면 컨테이너가 루트가 아닌 사용자로 실행할 수 있습니다. 데이터 전용 컨테이너는 한 번만 실행됩니다.
my-beautiful-service가 미리 사용하는 uid와 gid를 알고 있다고 가정합니다. 일반적으로 1000,1000입니다.

docker volume create 에서 사용할 볼륨에 대한 마운트 옵션을 (1.11에서) 지정할 수 있기 때문에 닫을 준비가 거의 된 것 같습니다.

바인드 마운트에서 지원되지 않기 때문에 uid/gid를 직접 지정할 수는 없지만 새로운 마운트 옵션과 함께 사용할 수 있는 많은 파일 시스템은 uid/gid 옵션과 함께 작동할 수 있습니다.

컨테이너 내부에 CIFS 드라이브를 마운트하려는 경우 문제가 여전히 해결된다고 생각하지만 다른 티켓이 되어야 합니까?

@michaeljs1990 컨테이너별로가 아니라 이렇게 할 수 있습니다(원하는 각 uid/gid 콤보에 대해 별도의 볼륨을 생성하지 않는 한).

@cpuguy83 , 이 문제를 피하기 위해 docker volume create 를 어떻게 사용해야 하는지 설명해 주시겠습니까?

오늘 도커 1.11에서 이 문제에 부딪쳤고 마운트된 드라이브의 파일에 쓸 수 있도록 도커 이미지를 설득하기 위해 고통스러운 재지거 작업을 수행해야 했습니다. 다른 사람에게 설명하려고 노력하는 것은 물론 다시 할 필요가 없다면 정말 좋을 것입니다.

이것이 당신이 묻는 것인지 확실하지 않지만 ...

FROM busybox
RUN mkdir /hello && echo hello > /hello/world && chown -R 1000:1000 /hello

"test"라는 이미지 위에 빌드

$ docker volume create --name hello
$ docker run -v hello:/hello test ls -lh /hello

위의 예에서 /hello 및 /hello/world 는 모두 1000:1000이 소유합니다.

내가 참조. 그래서 저는 비슷하지만 조금 다른 작업을 했으며 공유할 가치가 있습니다. 기본적으로 컨테이너 외부의 사용자에 대한 내 UID, GID, 사용자 이름 및 그룹을 공유하는 사용자를 Dockerfile에 추가했습니다. 모든 <...> 는 관련 값으로 대체된 것입니다.

FROM <some_image>
RUN groupadd -g <my_gid> <my_group> && \
    useradd -u <my_uid> -g <my_gid> <my_user>

그 후에 USER 를 사용하거나 나중에 su 를 사용하여 전환할 수 있습니다(예: 진입점 스크립트 또는 셸을 사용할 때). 이렇게 하면 내가 생성한 동일한 사용자였으므로 탑재된 볼륨에 쓸 수 있습니다. 컨테이너 내부에서 chown 를 추가로 사용하여 관련 항목에 대한 권한이 있는지 확인할 수 있습니다. 또한 sudo 를 설치하는 것도 이 작업을 수행할 때 일반적으로 현명한 조치입니다.

그것이 문제를 해결하는 동안, 이것은 모든 사용자를 위해 수행되어야 하기 때문에 내가 그것을 좋아하는지 모르겠습니다. 또한 저는 하드 코딩했지만(이런!) 템플릿을 사용하여 이를 좀 더 부드럽게 만들 수 있습니다. 이 심이 어떻게든 docker run 에 흡수될 수 있을지 궁금합니다. 이 작업을 수행하는 더 좋은 방법이 이미 있다면 그것이 무엇인지 알고 싶습니다.

호스트 사용자 uids/gids를 컨테이너 사용자 uids/gids와 --userns-remap 로 매핑하는 옵션이 있습니다. 개인적으로 나는 그것을 시도하지 않았습니다. 이 주제에 대한 좋은 토론을 참조하십시오. http://stackoverflow.com/questions/35291520/docker-and-userns-remap-how-to-manage-volume-permissions-to-share-data-betwee .

@cpuguy83 :

바인드 마운트에서 지원되지 않기 때문에 uid/gid를 직접 지정할 수는 없지만 새로운 마운트 옵션과 함께 사용할 수 있는 많은 파일 시스템은 uid/gid 옵션과 함께 작동할 수 있습니다.

uid/gid 인수를 허용할 수 있는 파일 시스템은 무엇이라고 생각하십니까? 나는 FAT가 가능하다는 것을 알고 있지만 이것은 이 스레드에서 제안된 다른 모든 것만큼이나 해키하게 느껴집니다.

IMO, Docker에는 두 가지 옵션이 있습니다.

1. 지정된 사용자/그룹으로 볼륨을 탑재하기 위한 공식 지원(컨테이너 내부에 정의된 사용자/그룹 이름 사용, 호스트가 컨테이너의 내부에 대해 이 지식을 가질 필요 없음).
2. 또는... USER 지시문(및 관련 런타임 플래그)을 제거하십시오.

루트가 아닌 사용자로 실행할 수 있는 반면 루트가 소유한 볼륨만 마운트할 수 있다는 것은 잘못된 기능입니다. 호스트와 컨테이너 간의 uid/gid 공유는 또 다른 잘못된 기능입니다.

@mehaase 볼륨은 컨테이너의 경로에 이미 있는 모든 항목의 소유권을 갖습니다. 컨테이너의 위치가 루트 소유인 경우 볼륨은 루트가 됩니다. 컨테이너의 위치가 다른 사람의 소유인 경우 볼륨이 해당 위치를 가져옵니다.

이에 대한 일종의 해결 방법이 좋을 것입니다. 컨테이너가 특별히 예상하지 않는 한 권한을 설정하는 사용자 지정 Dockerfile을 작성하지 않고 Elasticsearch, redis, couchDB 및 기타 여러 컨테이너와 같은 표준 컨테이너에 볼륨을 추가하는 것은 _매우_ 어렵습니다. 이것은 대부분 docker-compose의 docker run -v 명령 또는 volume: 지시문을 쓸모 없게 만듭니다.

@chrisfosterelli 왜 쓸모가 없습니까? 사용할 것으로 예상되는 파일/디렉토리의 소유권을 설정하는 것이 일반적이지 않다고 생각합니다.

@cpuguy83 권한과 볼륨을 설정하는 커스텀 도커파일을 사용하지 않고는 소유권 설정이 불가능해 보이기 때문에 볼륨 정의에 유용하지 않다고 생각합니다. 관련이 있는 경우 컨테이너를 호스트 파일 시스템에 바인딩하지 않습니다.

@chrisfosterelli 그러나 이러한 모든 표준 Dockerfile에는 이미 권한이 설정되어 있어야 합니다.

@chrisfosterelli 가 @cpuguy83 이라고 말하려고 하는 것 같아요. @chrisfosterelli가 틀렸다면 정정해주세요. 이러한 변수(UID, GID 등)가 동적이며 런타임(특히 내부적으로 소유하고 탑재된 볼륨에서 파일에 대해 wrt)을 수행하지만 현재로서는 이를 수행할 방법이 없습니다. 지금까지의 반응은 런타임에 결정되어서는 안 된다는 것이지만, 그러한 제안이 제시하는 근본적인 사용성 문제를 무시하는 것입니다. 이 중 하나라도 잘못 이해하고 있다면 언제든지 저를 수정해 주십시오.

@jakirkham 사용성 문제가 무엇인지 이해해서는 안됩니다.
파일은 이미지에 있으며 애플리케이션을 실행하는 데 필요한 소유권과 권한이 있어야 합니다. 볼륨 자체와 관련이 없습니다. 볼륨은 이미지에 설정된 대로 적용됩니다.

@cpuguy83 저는 조금 더 파고 들어 이것을 다음과 같이 분리했습니다. 시작할 때 /data 디렉토리를 생성할 Elasticsearch 컨테이너가 있다고 가정하고(데이터가 없는 경우) docker run -v /data elasticsearch 를 사용합니다. . /data 디렉토리는 $# root:root 소유가 되며 컨테이너 내부에서 elasticsearch 로 실행되는 데몬은 /data 에 쓸 수 없기 때문에 시작하지 못합니다.

사용자 지정 Dockerfile 없이도 Elasticsearch가 이 볼륨을 소유하도록 설정할 수 있다면 이상적일 것입니다. 하지만 이러한 종류의 문제는 업스트림 이미지에서 해결되어야 한다고 주장할 수 있을 것 같습니다.

@chrisfosterelli 소유권을 변경할 수 있는 드라이버와 같은 오버레이가 있다는 커널 메일링 리스트에 대한 이야기가 있지만 그런 것이 없이는 할 수 있는 일이 많지 않습니다. 궁금합니다. 볼륨 세계의 모든 파일을 읽고 쓰도록 하고 umask를 적절하게 설정하여 새 파일도 그렇게 할 수 있습니까? (나는 아직 시도하지 않았다).

@justincormack 나는 그렇게 생각하지만 컨테이너가 (호스트가 아닌) 볼륨에 데이터를 생성할 것으로 예상할 때는 작동하지 않는다고 생각합니다. 나는 이것이 일종의 이상한 문제라는 것을 이해하므로 현재 업스트림 Dockerfile 자체에서 mkdir -p && chmod 디렉토리로 수정하여 해결하고 있습니다.

@chrisfosterelli 그것이 내가 umask를 설정한다고 말한 이유입니다. umask가 000 (컨테이너에서) 모든 새 파일은 666 또는 777 권한으로 생성되고 마운트 포인트는 777 로 시작해야 합니다. 괜찮을까요? 권한이 항상 세계 읽기 및 쓰기인 경우 uid 및 gid가 중요하지 않아야 합니까?

@justincormack 네 맞습니다... 호스트에 탑재되지 않은 볼륨으로 도커 컨테이너를 만드는 동안 어떻게 할 수 있습니까?

@chrisfosterelli 흠, 좋은 질문입니다. 새 볼륨에 대한 권한이 기본 umask가 제공하는 것이므로 000 umask로 도커 데몬을 실행하고 볼륨이 전체 쓰기 가능한지 확인할 수 있습니다. 아마도 docker volume create 에 대한 몇 가지 권한 옵션이 있어야 합니다.

( chmod 를 실행하고 종료한 루트 컨테이너로 고칠 수 있지만 추악합니다)

생성 시 좋지 않습니다. 문제는 컨테이너에 경로가 없으면 경로가 루트로 생성된다는 것입니다. 이것은 전달된 사용자가 무엇이든 간에 틀림없이 수행될 수 있습니다.

@cpuguy83 사용자가 -u를 사용하여 전달하면서 생성하는 것이 더 합리적이라고 생각합니다. 사용자가 컨테이너 내부에서 어쨌든 볼륨을 쓰려고 할 것이기 때문입니다. 맞나요?

아래 단계를 사용하여 내가 선택한 사용자로 마운트할 수 있었습니다.

• 호스트의 파일을 소유한 사용자와 동일한 UID/GID를 사용하여 Docker 내부에 사용자를 생성합니다.
• 마운트 지점을 미리 생성하고 컨테이너의 대상 사용자에게 chown

인용 @chrisfosterelli :

나는 조금 더 파고들어 이것을 다음과 같이 분리했다: 시작할 때 디렉토리 /data를 생성할 elasticsearch 컨테이너가 있다고 가정하고(데이터가 없는 경우) docker run -v /data elasticsearch를 사용하십시오. /data 디렉토리는 root:root 의 소유가 되며 컨테이너 내에서 Elasticsearch로 실행되는 데몬은 이제 /data에 쓸 수 없기 때문에 시작에 실패합니다.

이것은 좋은 예입니다! Solr 이미지와 비슷한 예가 있습니다. Solr에는 하나 이상의 "코어"가 필요하며, 각각은 관련 구성 파일 및 인덱스 조각 모음입니다. 각 코어는 사용자 지정 이름을 가진 디렉토리 안에 있습니다. 예를 들어 products 라는 코어를 생성하려는 경우 경로는 /opt/solr/server/solr/products 입니다. 코어의 이름은 내가 선택하므로 Solr 이미지 관리자는 이미지에서 이 디렉토리를 미리 생성할 수 없습니다.

모든 문서를 다시 인덱싱할 필요 없이 이미지를 최신 Solr로 업그레이드할 수 있도록 인덱스 데이터를 저장하고 싶지만 볼륨을 /opt/solr/server/solr/products 에 마운트하면 root 의 소유입니다. solr 로 실행)은 실제로 아무 것도 쓸 수 없습니다. 상위 디렉토리 /opt/solr/server/solr 에는 다른 파일이 포함되어 있으므로 거기에도 볼륨을 마운트할 수 없습니다. (최신 Docker 용어에서는 내 볼륨을 "명명된 볼륨"이라고 부릅니다. 즉, 호스트의 지정된 경로에 마운트되지 않지만 나를 위해 Docker에서 완전히 관리하는 볼륨입니다.)

저는 Solr 이미지 유지 관리자와 이에 대해 이야기 했으며 몇 가지 해결 방법이 있지만(그리고 그는 도움을 주기 위해 이미지를 약간 변경했습니다.) 이 모든 것이 꽤 엉뚱하고 업스트림 이미지에 대한 사례별 변경이 필요합니다. 이 스레드에서 설명하는 기능을 사용하면 새 Dockerfile을 만들 필요 없이 _모든 이미지_를 더 확장할 수 있습니다.

@ctindel 아마도 ... 디렉토리가 이미 존재하지 않는 경우.

@cpuguy83 맞습니다 . 저도 동의합니다. 그것은 확실히 내 사용 사례였습니다. 컨테이너 실행을 위해 사용자 ID가 명시적으로 지정된 경우 디렉토리가 존재하지 않으면 루트로 디렉토리를 생성하는 것이 의미가 없는 것 같습니다.

@ cpuguy83 명명된 볼륨에서만 작동합니다.

@kamechen 무엇이 작동합니까?

@cpuguy83 명명된 볼륨을 사용하면 필요한 사용자 아래에 파일이 마운트됩니다.

@eciuca 글쎄요.... 에 달려있습니다. 명명된 볼륨이 비어 있거나 명명된 볼륨의 데이터가 우연히 필요한 동일한 사용자에 의해 생성된 경우.

@andrewmichaelsmith가 제기한 문제에 대한 해결책이 있었나요?

우리는 이것으로 해결될 문제에 부딪히고 있습니다(제 생각에는). 개발자의 홈 디렉토리에 대한 NFS 공유가 있습니다. 개발자는 /home/dev/git/project를 Docker에 마운트하고 싶지만 루트 스쿼시가 활성화되어 있기 때문에 마운트할 수 없습니다.

이것은 루트가 /home/dev/git/project에 액세스하는 것을 금지하므로 docker mount /home/dev/git/project를 시도하고 실행할 때 lstat 권한 거부 오류가 발생합니다.

bindfs 를 사용하여 이 문제를 해결할 수 있다고 생각합니다.
docker의 -v ... 를 사용하여 임시 위치에 볼륨을 마운트한 다음 bindfs를 사용하여 다른 사용자로 필요한 위치에 마운트합니다.

@piccaso , 내가 @andrewmichaelsmith 를 이해한 방식은 문제가 rootsquash로 인해 호스트 측의 bind-mount가 실패한다는 것입니다. 그러나 bindfs는 실제로 해결 방법으로 여전히 사용될 수 있지만 이번에는 호스트 측에서 사용됩니다. 먼저 호스트에서 FUSE를 사용하여 루트가 아닌 사용자로 임시 위치에 nfs 공유를 바인딩 마운트한 다음 -v ... 를 사용하여 도커에 해당 임시 폴더를 마운트합니다.

bindfs(적어도 FUSE에서는)에는 상당한 CPU 오버헤드가 있습니다.

예, bindfs는 매우 바람직하지 않습니다. CoW 파일 시스템보다 느립니다.
도움이 될 수 있는 마운트 시 uid/gid 이동을 허용하기 위해 커널에서 수행 중인 몇 가지 작업이 있습니다.

도움이 될 수 있는 마운트 시 uid/gid 이동을 허용하기 위해 커널에서 수행 중인 몇 가지 작업이 있습니다.

이것은 컨테이너 내부에서 uid/gid를 다시 매핑하려는 사용 사례를 해결하는 데에만 도움이 될 것입니다. 도커 데몬에 의해 실행된 마운트 자체는 여전히 호스트에서 루트로 실행됩니다. 내 이해는 커널 바인드 마운트가 루트로만 생성될 수 있다는 것입니다. 루트가 아닌 사용자가 마운트를 수행할 수 있도록 변경하는 작업이 있는지 확실하지 않습니다(나는 Linux가 마운트를 처리하여 이치에 맞는지 판단하는 방법에 대해 거의 알지 못합니다).

@NikolausDemmel 나는 그것이 바뀔 것이라고 의심합니다. mount 시스템 호출에는 CAP_SYS_ADMIN이 필요합니다. 이는 루트가 아닌 사용자에게 주어지거나 컨테이너의 루트 사용자에게 제공되는 것이 아닙니다.

@ cpuguy83 설명 감사합니다. 즉, root-squash를 사용한 NFS 마운트인 호스트 폴더에 도커 볼륨을 마운트하는 것은 가까운 장래에 작동하지 않을 것임을 의미합니다(당신이 말했듯이 마운트 시스템 호출의 제한으로 인해) bindfs

죄송합니다. OP가 컨테이너 내부의 UID/GID 변경에 대해 질문했기 때문에 이것은 약간 OT였습니다. 그러나 그것은 동전의 이면과 같으며 위의 논의에서 언급되었습니다. 그 구분을 명확히 하고 싶었을 뿐입니다.

Mac용 Docker를 실행 중이고 볼륨을 마운트했지만 웹 서비스가 파일에 액세스할 수 있도록 설정된 권한을 얻지 못하는 것 같습니다. 이 문제를 해결하려면 어떻게 해야 합니까? 파마를 변경하고 그룹을 스태프로 설정하려고 시도했지만 알파인에는 스태프 그룹이없는 것 같습니다.

여기가 가장 좋은 곳이 아니라면 죄송합니다. 며칠 동안 고생했고 더 좋은 곳이 생각나지 않았습니다.

@NikolausDemmel : 우리는 일부 생물 정보학 작업에 Docker를 사용하려고 합니다. NFS를 통해 root-squash로 마운트된 여러 거대한 파일 시스템이 있습니다. 거대한 시퀀스 데이터(fastq)를 읽고 게놈 읽기가 데이터 저장소에 정렬된 다소 작은 BAM 파일을 작성합니다. 현재 사용자 지정 이미지를 수행하여 컨테이너 내부에 사용자를 생성하고 마지막에 USER를 사용하여 작동하도록 하여 도커를 사용할 수 있지만 몇 가지 이유로 문제가 있습니다.

1. 다른 사람의 Docker 이미지를 사용하려면 사용자 지정 Dockerfile로 다시 빌드해야 합니다.
2. 각 로컬 사용자에 대한 사용자 지정 도커 이미지를 생성해야 하거나 단일 "서비스" 계정을 사용하고 FS에서 사용자의 활동을 구별할 수 없습니다.

Bindfs 또는 userNS로 이 문제를 해결할 수 있습니까?

나는 같은 문제에 직면하고 있다고 생각합니다. 제 사용 사례는 다음과 같습니다.
Docker 이미지는 주어진 프로젝트에 대한 이식 가능한 빌드 도구를 보유하고 있으며, docker run -v ./:/src/ image 또는 docker-compose 파일의 동등한 항목을 사용하여 상대 경로로 볼륨 마운팅을 사용합니다. 빌드가 자동으로 시작되고 연결된 볼륨의 하위 폴더에 새 파일이 생성됩니다.
때때로 우리는 호스트에서 빌드된 파일을 사용하고 싶지만 docker를 실행한 호스트 사용자가 아니라 docker의 사용자가 여전히 파일을 소유하고 있다는 사실이 문제를 어렵게 만드는 경향이 있습니다.

내가 여기서 특히 잘못된 일을 하고 있습니까?

@rlabrecque 는 도커 사용자의 ID를 호스트의 ID와 일치시키는 것에 대해 이전에 내 게시물을 참조하십시오. 나는 이 접근 방식을 사용했고 그것은 우리에게 정말 잘 작동합니다. 기본적으로 HOST_UID=$(id -u) 및 HOST_GID=$(id -g) 를 실행하고 아래 두 명령에서 $HOST_GID 및 $HOST_UID를 확장하는 Dockerfile을 생성합니다.

RUN groupadd -g $HOST_GID mygroup
RUN useradd -l -u $HOST_UID -g mygroup myuser

ID가 채워진 생성된 Dockerfile을 사용하여 이미지를 빌드합니다.

@haridsv 비슷한 작업을 수행했으며 Linux에서 훌륭하게 작동합니다. 그러나 Windows에서는 작동하지 않는 것 같습니다. 마운트 내부의 파일은 여전히 ​​루트 소유입니다.

inotifywait 를 사용하여 이 문제를 해결했습니다. 도커 이미지 내에서 실행하려면 inotify-tools를 설치해야 합니다. 대신 호스트 시스템에서 실행할 수 있지만 휴대용 솔루션을 원했습니다.

RUN export DEBIAN_FRONTEND=noninteractive \
  && apt -y update \
  && apt -y install inotify-tools \
  && inotifywait -m -r /mount -e create --format '%w%f' \
    | while read f; do chown $(stat -c '%u' /mount):$(stat -c '%g' /mount) $f; done

이것은 inotifywait가 /mount 디렉토리에 생성된 새 파일이나 디렉토리를 감시하도록 지시함으로써 작동합니다. 하나를 발견하면 소유권을 /mount 폴더와 동일한 사용자 및 그룹으로 변경합니다. 호스트 사용자/그룹이 컨테이너에 없는 경우를 대비하여 둘 다의 정수 표현을 사용했습니다. 모든 것이 루트로 실행되기 때문에 컨테이너 내부에서는 누가 그것을 소유하고 있는지는 중요하지 않습니다. 컨테이너 외부에서 호스트 파일 시스템은 /mount에 마운트된 디렉토리와 동일한 소유권을 보여줍니다.

기존 파일 및 디렉토리의 소유권을 유지하기 위해 의도적으로 새로 생성된 파일 및 디렉토리의 소유권만 설정하도록 설계했습니다. 파일 시스템이 마운트될 때마다 chown -R 문으로 모든 것을 날려버리는 것보다 안전합니다. 프로젝트에 균일한 권한이 적용되고 보다 효율적으로 실행되는 더 간단한 솔루션을 원하는 경우 inotify-hookable 을 살펴보세요.

경고: 하위 디렉토리당 하나의 inotify 감시가 설정되므로 사용자당 최대 inotify 감시 수에 도달할 수 있습니다. 기본 최대값은 8192입니다. /proc/sys/fs/inotify/max_user_watches에 작성하여 늘릴 수 있습니다.

호스트 측 스크립트를 사용하여 이미지를 다시 빌드할 필요가 없도록 마운트된 볼륨을 chown 했습니다.

#!/bin/bash
set -e

DOCKER_IMAGE=<docker_image>
COMMAND=<internal_command>

DOCKER_USER=docker-user
DOCKER_GROUP=docker-group

HOME_DIR=/work
WORK_DIR="$HOME_DIR/$(basename $PWD)"

PARAMS="$PARAMS -it --rm"
PARAMS="$PARAMS -v $PWD:$WORK_DIR"
PARAMS="$PARAMS -w $WORK_DIR"

USER_ID=$(id -u)
GROUP_ID=$(id -g)

run_docker()
{
  echo \
    groupadd -f -g $GROUP_ID $DOCKER_GROUP '&&' \
    useradd -u $USER_ID -g $DOCKER_GROUP $DOCKER_USER '&&' \
    chown $DOCKER_USER:$DOCKER_GROUP $WORK_DIR '&&' \
    sudo -u $DOCKER_USER HOME=$HOME_DIR $COMMAND
}

if [ -z "$DOCKER_HOST" ]; then
    docker run $PARAMS $DOCKER_IMAGE "$(run_docker) $*"
else
    docker run $PARAMS $DOCKER_IMAGE $COMMAND "$*"
fi

호스트 디렉토리에서 파일 시스템 ACL을 사용하는 것은 어떻습니까? 그렇게 하면 디렉토리 내부에 새로 생성된 파일에 특정 권한을 적용하도록 파일 시스템에 지시할 수 있습니다. 호스트 수준에서 ACL을 설정하면 컨테이너에서 데이터를 수정하는 경우에도 발생합니다.

@jjjjjjjjjjjjjjr _ _

@kamechen 은 명명된 볼륨이 "그냥 작동"하는 것이 맞는 것 같습니다. 명명된 볼륨의 경우 기존 권한이 "역효과"를 일으켜 볼륨 권한을 변경하는데, 저는 개인적으로 이것을 버그(#28041)로 생각합니다.

@thegecko , 이 접근 방식을 더 취하고 진입점 내에서 사용자를 생성하지 않는 이유는 무엇입니까?

다음은 내 예입니다. 마운트된 디렉토리의 소유자를 감지하고 동일한 UID로 사용자를 생성하고 이 사용자에서와 같이 명령을 실행합니다.

도커파일

FROM ubuntu

RUN mkdir /project
VOLUME /project

ENV GOSU_VERSION 1.9
RUN set -x \
    && apt-get update && apt-get install -y --no-install-recommends ca-certificates wget && rm -rf /var/lib/apt/lists/* \
    && dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')" \
    && wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch" \
    && wget -O /usr/local/bin/gosu.asc "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch.asc" \
    && export GNUPGHOME="$(mktemp -d)" \
    && gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 \
    && gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu \
    && rm -r "$GNUPGHOME" /usr/local/bin/gosu.asc \
    && chmod +x /usr/local/bin/gosu \
    && gosu nobody true \
    && apt-get purge -y --auto-remove ca-certificates wget

ADD entrypoint.sh /

ENTRYPOINT ["/entrypoint.sh"]

CMD /project/run.sh

진입점.sh

#!/bin/sh

USER=dockeruser
VOLUME=/project
UID="$(stat -c '%u' $VOLUME)" && \
useradd --uid "$UID" "$USER" && \
ls -l "$VOLUME" && \
exec gosu "$USER" "$@"

실행.sh

#!/bin/sh

echo "Running as \"$(id -nu)\""

sudo docker build -t test . && sudo docker run --rm -v /tmp/docker-test/:/project test:latest 를 실행하면 다음과 같이 출력됩니다.

total 12
-rw-r--r-- 1 dockeruser dockeruser 990 Dec 12 10:55 Dockerfile
-rwxr-xr-x 1 dockeruser dockeruser 156 Dec 12 11:03 entrypoint.sh
-rwxr-xr-x 1 dockeruser dockeruser  31 Dec 12 11:01 run.sh
Running as "dockeruser"

이 문제를 고려한 사람이 있습니까? 볼륨이 컨테이너와 동일한 gid 및 uid를 갖도록 하면 루트를 사용하지 않도록 컨테이너를 관리하기가 더 어려워집니다. Docker의 모범 사례 는 가능하면 루트로 서비스를 실행하지 않는 것이 좋습니다. 그러나 호스트와 컨테이너에서 gid 및 uid를 설정하지 않아도 도커를 인기 있게 만든 사용 편의성을 무너뜨릴 수 있습니까?

@AndreasBackx 볼륨을 사용하면 이미지가 마운트 경로에 데이터가 있다고 가정하면 작동합니다.
바인드를 사용하면 호스트 경로의 UID/GID가 사용됩니다.

끔찍하게 느린 FUSE와 같은 것을 사용하지 않는 한 원본을 변경하지 않고 파일/디렉토리의 UID/GID를 다른 것으로 매핑하거나 변경할 방법이 현재 없습니다(커널 지원 없음).

하지만 잠시 뒤로 물러나자.
Docker는 여기서 일을 더 어렵게 만드는 것이 아닙니다.
컨테이너의 UID/GID는 호스트의 UID/GID와 동일합니다.. 사용자/그룹 이름이 일치하지 않더라도 여기서 중요한 것은 UID/GID입니다.
도커가 없는 경우와 마찬가지로 서비스에 사용하려는 uid/gid를 가져와 관례에 맞지 않게 사용해야 합니다.
파일 소유권을 설정하기 위해 uid/gid가 /etc/passwd 또는 /etc/group 에 있을 필요는 없습니다.

@cpuguy83 설명 감사합니다.

오늘 node 파이프라인을 생성하는 동안 이 문제가 발생했습니다. 내 호스트 사용자 UID는 1000이고 node 이미지 는 해당 특정 UID로 사용자 지정 사용자를 생성합니다. 이에 대한 문제도 있습니다.

노드 사용자를 사용하고 계속 진행하지만 약간 더러워진 느낌이 듭니다. @cpuguy83 에서 "잠시 뒤로 물러나자"에 대해 쓴 내용을 공유하지만 때로는 문제를 해결하기 어려울 수 있습니다.

중복 IDS를 허용하기 위해 usermod 에서 -o 옵션을 찾았습니다. 합법적인 옵션인 것 같습니다.

RUN usermod -o -u 1000 <user>

이것이 합리적인 방법으로 해결되지 않은 이유가 확실하지 않습니다.

docker run -it -u 1000:4211 -v /home/web/production/nginx_socks:/app/socks -e SOCKS_PATH=/app/socks --name time_master  time_master

로그인하여 보려면:

drwxr-xr-x    8 geodocr_ geodocr       4096 Jun  4 18:51 .
drwxr-xr-x   57 root     root          4096 Jun  6 21:17 ..
-rwxrwx---    1 geodocr_ geodocr        140 Jun  4 18:49 .env
-rwxrwx--x    1 geodocr_ geodocr         78 Jun  4 18:49 entrypoint.sh
drwxrwxr-x    2 geodocr_ geodocr       4096 Jun  4 18:51 handlers
-rwxrwx---    1 geodocr_ geodocr        242 Jun  4 18:49 requirements.txt
-rwxrwx---    1 geodocr_ geodocr       1270 Jun  4 18:49 server.py
drwxr-xr-x    2 root     root          4096 Jun  6 21:00 socks
drwxr-xr-x   10 geodocr_ geodocr       4096 Jun  4 18:51 utils

dockerfile은 구체적으로 다음을 수행합니다.

RUN adduser  -D -u 1000 $USER 
#
RUN addgroup $GROUP -g 4211 
#
RUN addgroup $USER $GROUP 
RUN mkdir /app/socks
USER $USER  
#

컨테이너의 사용자도 선택되지 않고 명령을 실행하는 사용자도 선택되지 않은 경우 이 볼륨이 루트로 마운트된다는 것은 의미가 없습니다. RUN 명령이 명령을 실행하는 사용자로 마운트되었는지, 디렉토리를 소유한 사용자인지, Dockerfile에 지정된 사용자인지 이해할 수 있습니다.

이들 중 어느 것도 루트가 아니므로 루트로 마운트하는 것은 버그인 것 같습니다.

또한 방금 확인하여 볼륨을 생성한 다음 마운트가 작동합니다. 그래서 여전히 버그입니다.

@disarticulate 호스트 경로를 루트가 아닌 다른 경로로 지정하려면 호스트 경로를 변경해야 합니다.

이것이 전에 언급된 적이 없다고 생각하지만 이 버그는 Docker에 의존하여 호스트 볼륨을 생성할 때 특히 성가십니다. Docker는 마운트하는 디렉토리의 소유자가 다른 경우에도 항상 루트로 호스트 볼륨을 생성하는 것 같습니다.

여기서 해야 할 올바른 일은 이미지의 USER 에 속하는 소유권 권한으로 볼륨을 만드는 것 같습니다.

@jalaziz 컨테이너의 사용자가 호스트에 존재하지 않을 때 어떻게 해야 하나요? 컨테이너의 주요 이점 중 하나는 해당 종속성(사용자 포함)을 호스트에 노출할 필요가 없다는 것입니다.

@taybin Docker가 컨테이너 사용자의 uid:gid 로 폴더를 생성하거나 폴더가 컨테이너 내부에 존재하는 경우 동일한 uid:gid 및 마스크로 호스트 폴더를 생성할 것으로 예상합니다.

참고: 폴더가 호스트에 이미 있는 경우 Docker 변경 권한이 필요하지 않습니다.

@taybin 정확히 @frol 이 설명한 대로. 컨테이너의 uid:gid 를 사용해야 합니다.

그러나 이것은 현재 접근 방식에 대한 일반적인 문제를 드러냅니다. 컨테이너가 쓰기를 허용하고 해당 uid:gid를 기반으로 호스트 디렉토리에 대한 권한을 설정하는 데 사용하는 uid를 알아야 합니다. 업스트림 작성자가 uid를 변경하면 권한이 중단됩니다. 모든 것이 매우 연약해 보입니다.

제 경우에는 사용 중인 도커 이미지를 명시적으로 제어할 필요가 없었습니다(Dockerfile을 원하는 대로 편집할 수 없었습니다).

그래서 나는 이것을 시도했다.

docker run -it -u $(id -u $USER):$(id -g $USER) -v $(pwd):/src -w /src node:latest npm run build

./built-app 라는 폴더가 생성됩니다. 그러나 소유자는 여전히 엄격한 권한이 있는 root .

내 해결 방법은 다음과 같습니다.

docker run -it -v $(pwd):/src -w /src node:latest /bin/bash -c "npm run build; chmod -R 777 ./built-app"

여전히 root 소유자가 있지만 권한이 완화되었습니다. 그런 다음 내 호스트 OS(Ubuntu)가 sudo 권한 없이 ./built-app 에 액세스할 수 있었습니다.

@ rms1000watt 다음 명령을 시도 했습니까?

docker run -it -v $(pwd):/src -w /src node:latest /bin/bash -c "npm run build; chown -R ${UID}:${GID} ./built-app"

호스트의 UID 및 GID 를 파일 자체에 직접 사용하므로 작동해야 합니다. chmod -R 777 를 사용하는 것은 일반적으로 좋지 않습니다.

@saada 웁스! 좋은 전화입니다. 한번 해볼께요.

나는 이것을 읽고 Docker 컨테이너에서 _UID 및 GID가 작동하는 방식을 이해하는 접근 방식을 수행할 수 있습니다.
https://medium.com/@mccode/understanding -how-uid-and-gid-work-in-docker-containers-c37a01d01cf

기본적으로 로컬 시스템의 루트가 컨테이너의 루트와 동일하고 둘 다 동일한 UID를 공유한다는 것을 의미하는 단일 커널과 단일 공유 uid 및 gid 풀이 있습니다.

아파치 서버가 있고 내 webapp 파일을 아파치 컨테이너와 공유하여 호스트에서 수정하고(개발, 텍스트 편집기를 사용하여 변경) 컨테이너에서 실행 중인 프로세스의 결과를 보고 싶습니다. 때로는 그 프로세스에서 새 파일을 작성하고 권한으로 기본 동작을 변경하지 않으면 루트 사용자가 파일을 생성하고 내 로컬 사용자가 더 이상 파일을 수정할 수 없습니다.

내가 한 것은 내 dockerfile에 이것을 추가하는 사용자 정의 이미지를 생성하는 것입니다.

RUN adduser -D -u 1002 dianjuar -G www-data
USER dianjuar

내 docker-compose.yml 를 누구나 사용할 수 있도록 하려면 빌드 프로세스에 일부 매개변수를 넣어야 합니다.

다음은 쉽게 이식할 수 있는 방식으로 런타임에 userid/groupid를 할당하기 위한 컨테이너 패턴입니다. https://github.com/Graham42/mapped-uid-docker

내가 따랐던 방법:

1- 호스트 서버에 디렉토리 생성
2- userid 및 groupid = 1000인 사용자에 대한 권한 변경
3- docker-compose up 실행
컨테이너를 확인하고 모든 것이 정상입니다.

참고: 호스트 서버에서 루트 사용자를 사용하고 있었고 uid = 1000인 루트가 아닌 사용자를 사용하는 경우 권한에 대해 걱정하지 않고 볼륨을 탑재할 수 있다고 가정하지만 아직 테스트하지는 않았습니다. 비슷한 방식으로 따라한 사람이 있습니까?

일반적인 문제:

• docker swarm, 따라서 CAPP_ADD를 사용할 수 없으며 bind-mount는 솔루션이 아닙니다.
• 두 개의 서로 다른 이미지가 있는 두 개의 컨테이너가 동일한 볼륨을 공유하므로 둘 다에 있는 서로 다른 사용자/그룹 데이터베이스
• 예를 들어 www-data에 대한 액세스 권한이 있어야 합니다(즉, 인증서 다운로더를 암호화합시다).
• 다른 하나는 www-data(즉, nginx)도 사용합니다.
• 그러나 세 번째는 사용자 openldap(즉, openldap 서버)의 액세스가 필요합니다.
• 너무 간단한 chmod도 솔루션이 아닙니다.

즉, let's encrpt에서 도메인에 대한 SSL 인증서를 가져오는 웹 서버와 인증서를 재사용하려는 동일한 도메인에 대한 OpenLDAP 서버가 있습니다.

정확히 동일한 문제가 발생하는 다른 조합이 있습니다.

어떤 아이디어, 이것을 해결하는 방법?

Docker 없이 어떻게 이 문제를 해결할 수 있습니까? 이것은 Docker 전용이 아닙니다.
문제.

2018년 1월 12일 금요일 오전 10시 24분, Marc Wäckerlin [email protected]
썼다:

일반적인 문제:

• docker swarm, 따라서 CAPP_ADD를 사용할 수 없으며 bind-mount는
  해결책
• 두 개의 다른 이미지가 있는 두 개의 컨테이너는 동일한 볼륨을 공유하므로
  둘 다에 서로 다른 사용자/그룹 데이터베이스
• 예를 들어 www-data에 대한 액세스 권한이 있어야 합니다(예:
  인증서 다운로더)
• 다른 하나는 www-data(즉, nginx)도 사용합니다.
• 그러나 세 번째 것은 사용자 openldap(즉, openldap
  섬기는 사람)
• 너무 간단한 chmod도 솔루션이 아닙니다.

즉, 도메인에 대한 SSL 인증서를 가져오는 웹 서버가 있습니다.
let's encrpt와 동일한 도메인에 대한 OpenLDAP 서버에서
인증서를 재사용합니다.

정확히 동일한 문제가 발생하는 다른 조합이 있습니다.

어떤 아이디어, 이것을 해결하는 방법?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/2259#issuecomment-357267193 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAwxZgyvdCwGGVkUqCxK9nDFw1zxSKjUks5tJ3kXgaJpZM4BGxv9
.

--

• 브라이언 고프

Swarm이 없어도 docker: bind-mount에서 해결할 수 있습니다.

CAP_ADD가 없기 때문에 docker-swarm 특정 문제입니다.

@mwaeckerlin 바인드 마운트는 다른 사용자 ID에 매핑할 수 없습니다.
그러나 swarm으로도 마운트를 바인딩할 수 있습니다. .... CAP_ADD가 필요한 이유는 무엇입니까?

CAP_ADD가 없으면 도커 내부 마운트가 실패합니다.

그러나 내 의견을 작성하여 가능한 솔루션을 얻었지만 불행히도 두 이미지 모두에서 Dockerfile 를 변경해야 하므로 라이브러리 또는 기타 타사 이미지에서는 작동하지 않습니다.

• 모든 Dockerfiles에서 명시적으로 지정된 공통 그룹 ID로 그룹을 만듭니다.
• 그룹에 권한을 부여

@mwaeckerlin 컨테이너 내부에 마운트해야 하는 이유는 무엇입니까?

도커 옵션 -v 으로 사용자/그룹을 지정할 수 없기 때문입니다.

위에 지정된 아이디어는 다음과 같습니다. 컨테이너 내부에 바인딩 마운트한 다음 대상에 대한 chown은 소스를 변경하지 않아야 합니다.

@mwaeckerlin 바꾸면 여기저기 다 바뀝니다. 이것이 이 문제의 핵심입니다.
바인드 마운트된 파일/디렉토리를 Chowning/Chmoding하면 두 위치가 모두 변경됩니다.

또한 컨테이너 내부에 마운트할 필요가 없습니다 --mount type=bind,source=/foo,target=/bar

예, 방금 도커 외부에서 테스트 했으므로 위의 아이디어는 잘못되었습니다.

내가 도커에서 자주 보는 주요 문제는 사용자, 그룹이 다른 이미지에서 동일하지 않다는 것입니다. 동일한 사용자 이름이나 그룹 이름이 둘 다에 존재하더라도 종종 ID가 다릅니다.

다음과 같은 것이 어떤 경우에는 최소한 도움이 될 것입니다. --mount type=bind,source=/foo,target=/bar,user=me,group=mine

이 주제에 대한 권장 사항 또는 모범 사례: docker swarm의 다른 이미지에서 다른 사용자의 공유 볼륨 사용자?

1. 볼륨을 공유하지 마십시오
2. uid/gids 동기화
3. 공유하는 모든 사용자에 대해 권한이 충분히 허용되는지 확인합니다.
4. 호스트에서 퓨즈 마운트를 사용하여 각 컨테이너에 대해 다른 uid/gid에 바인딩하십시오.

4번 항목에 대해 자세히 설명해 주시겠습니까?
그렇게 하는 방법에 대한 실용적인 예가 될 수 있습니까?

2018년 1월 12일 금요일 17:27 Brian Goff, 알림 @github.com 작성:

>

1. 볼륨을 공유하지 마십시오
2. uid/gids 동기화
3. 공유하는 모든 사용자에 대해 권한이 충분히 허용되는지 확인합니다.
4. 호스트에서 퓨즈 마운트를 사용하여 각각에 대해 다른 uid/gid에 바인딩하십시오.
   컨테이너

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/2259#issuecomment-357282169 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AHSjvgjb0BFbJhZ1VWM-pLGfa7tRBvDNks5tJ4VPgaJpZM4BGxv9
.

https://bindfs.org/ 와 같은 것을 사용 -- 이미 구현한 Docker 볼륨 플러그인이 하나 이상 있습니다(https://github.com/lebokus/docker-volume-bindfs는 Google을 통해 찾은 첫 번째 결과입니다). .

볼륨을 마운트 한 후 권한을 변경할 수 없습니다. 누구에게나 있습니까?

해결 방법:
이것을 Dockerfile에 추가
RUN echo "if [ -e container_volume_path ]; then sudo chown user_name container_volume_path; fi" >> /home/user_name/.bashrc
볼륨이 마운트된 후 container_volume_path 의 소유권이 변경됩니다.

uid와 gid를 매핑할 수 있다는 것은 도커 볼륨 처리에 불가사의한 누락 요소처럼 보입니다. 가장 놀라운 방법은 이를 포함하는 것이며 제안된 수정 사항은 투박하고 발견하기가 더 어렵지만 모범 사례 이점을 제공하지 않습니다.

답장:
1) 볼륨을 공유하지 마십시오

• 좋지만 매핑 uid/gid에 대한 논의에는 중요하지 않습니다.
  2) uid/gids 동기화
• 이것이 기능의 의도이지만 Dockerfile에서 chown을 강제 실행하지 않습니다.
  3) 공유하는 모든 사람에게 충분한 권한이 있는지 확인합니다.
• 이것은 간단한 매핑일 수 있는 경우 Dockerfile에 정의된 동작에 다시 의존합니다.
  4) 호스트에서 퓨즈 마운트를 사용하여 각 컨테이너에 대해 서로 다른 uid/gid를 바인딩합니다.
• 좋은 조언, 그것은 또한 야크 면도처럼 보입니다.

@colbygk

간단한 매핑이 될 수 있을 때

그것이 문제입니다. vfs 계층에서 지원하지 않기 때문에 "단순 매핑"을 수행할 수 없습니다.
일부 파일 시스템은 소유권을 매핑하는 기능(예: bindfs 또는 nfs)을 제공하지만 일반적인 경우에 이를 구현하는 것은 현재 불가능합니다.

예를 들어 다음과 같은 상황에서 공유 볼륨이 필요합니다.

공유 인증서

• 컨테이너 1은 모든 호스팅된 도메인에 대해 암호화를 처리하는 역방향 프록시입니다.
• 컨테이너 2는 해당 도메인의 인증서도 제공해야 하는 ldap 서버입니다.

솔루션: 이미지 컨테이너 2는 컨테이너 1과 동일한 이미지에서 상속하고 공통 기본 이미지는 공통 그룹을 생성한 다음 두 컨테이너 모두 동일한 그룹 액세스 권한을 가집니다.

Dockerfile 공통 베이스 :

RUN groupadd -g 500 ssl-cert

letsencrypt-config.sh 이미지를 암호화하자 :

chgrp -R ssl-cert /etc/letsencrypt

Dockerfile mwaeckerlin/reverse-proxy :

RUN usermod -a -G ssl-cert www-data

Dockerfile 의 mwaeckerlin/openldap :

RUN usermod -a -G ssl-cert openldap

그게 다야

이 모든 것은 진입점 또는 빌드 프로세스 중에 userperms를 변경하여 전체 도커가 다른 사용자에서 실행되도록 하는 방법을 보여줍니다.

하지만 지난 3일 동안 웹을 검색한 후 중요한 포인트를 놓쳤을 수도 있습니다.
위 또는 다른 방법으로 연결된 권장 사항 및 (해결 방법)은 어떤 식으로든 작동하지 않습니다.

컨테이너에 마운트된 모든 볼륨은 항상 컨테이너 내부의 root:root 가 소유합니다. UID/GID가 일치하는지 여부에 관계없이 호스트에서 소유자를 미리 변경합니다.

내 관점에서 보면 아주 기본적인 일을 하려고 하는 내가 어리석다는 느낌을 지울 수 없습니다.

• 윈도우 10 프로 1803(17134.112)
• Windows용 Docker 18.03.1-ce-win65(17513)
• Hyper-V 및 Ubuntu가 포함된 Windows WSL

문서 루트가 호스트에 마운트된 일반 apache2 컨테이너를 시작하려고 하므로 도커 컨테이너에서 즉시 테스트하면서 PHP 소스 코드에서 개발할 수 있습니다.

root<strong i="16">@win10</strong>:# docker run --rm -v /c/Users/<MyUser>/Development/www-data:/var/www/html -it httpd:2.4 /bin/bash

도커 컨테이너 내부에서 디렉토리 __/var/www/html_은 항상 _ root:root_ 소유이므로 내 PHP 앱은 해당 폴더 내의 데이터를 열거나 쓸 수 없습니다.
아직 아무것도 작동하지 않았습니다... :(

합리적으로 우아한 솔루션을 찾는 사람들은 @elquimista 가 여기에서 제안한 것을 확인하십시오. 나는 이것을 테스트했고 잘 작동합니다

우리는 운 좋게 https://github.com/boxboat/fixuid#specify -paths-and-behavior-across-devices를 사용해 왔습니다. 또한 호스트의 사용자와 일치하도록 컨테이너 내부의 사용자를 설정합니다.

다음은 이미지의 구성 예입니다.

$ cat /etc/fixuid/config.yml
user: lion
group: lion
paths:
  - /home/lion
  - /home/lion/.composer/cache
  - /tmp

실행하려면:

$ docker run --rm -it --init \
    -u 1000:1000 \
    -v `pwd`:/app \
    -v "$HOME/.composer/cache:/home/lion/.composer/cache" \
    --entrypoint='fixuid' \
    php:7.2-cli \
        /bin/bash

이것은 유닉스 권한 및 소유권을 지원하지 않는 스토리지 시스템을 사용할 때에도 문제가 됩니다. 이 경우 파일을 chown하려는 시도가 실패하기 때문에 컨테이너 내부에서 사용할 올바른 uid를 얻을 수 있도록 저장소를 마운트해야 합니다. 컨테이너 외부의 소유권에 관계없이 특정 uid가 소유한 파일을 표시하도록 docker에 지시하는 방법이 있으면 작업을 단순화할 수 있습니다.

@tlhonmey

특정 uid가 소유한 파일을 표시하도록 docker에 지시하는 방법이 있는 경우

사용자 정의 파일 시스템(예: bindfs) 없이는 없습니다.

@tlhonmey 예, 일부 심볼릭 링크를 사용하여 "유닉스 권한을 지원하지 않는 스토리지 시스템" 문제를 해결할 수 있었습니다.

기본적으로 NTFS 드라이브에서 마운트하면 -v ./HostNtfsStuff:/data/ntfsMount 에 항목을 넣은 다음 심볼릭 링크를 만들고 ln -s -T /data/ntfsMount /var/lib/myApp && chown -Rh myApp:myApp /var/lib/myApp/

당신도 테스트할 수 있습니다: su myApp -c 'echo foo > /var/lib/myApp/bar' && cat /data/ntfsMount/bar

내 용도는 Windows 개발자가 MySQL 컨테이너를 실행하고 탑재된 볼륨을 유지할 수 있도록 하는 것이지만 많은 앱에 적용됩니다.

따라서 솔루션은 많은 uid:gid 쌍을 수동으로 관리하고 호스트 또는 도우미 스크립트에서 충돌하지 않기를 바랍니다.

작동하게 하는 _하나의_ 방법이 있지만 Dockerfile 내에서 미리 준비해야 합니다.

RUN mkdir -p /var/lib/redis ; chown -R redis:redis /var/lib/redis
VOLUME ["/var/lib/redis"]
ENTRYPOINT ["usr/bin/redis-server"]
USER redis

(나는 이 예제를 테스트하지 않았으며, 크롬 컨테이너에서 작업하고 있으며 _separate_ X11 컨테이너에 표시됩니다. .... )

나는 오늘까지 마지막 기술을 사용하고 있었는데 컨테이너 볼륨을 마운트하려고 하다가 부러졌습니다. 분명히 당신은 그렇게 할 수 없습니다. 볼륨이 루트로 생성되고 내부 앱이 사용자로 쓸 수 없습니다. VOLUME 문서에 설명된 자동 채우기는 바인드 마운트에서도 작동하지 않는 것 같습니다.

나는 Dockerfile 모범 사례 를 읽고 헬퍼 스크립트를 추천하는 것을 보았습니다.

#!/usr/bin/env bash
set -e

if [ "$1" = 'postgres' ]; then
    chown -R postgres "$PGDATA"

    if [ -z "$(ls -A "$PGDATA")" ]; then
        gosu postgres initdb
    fi

    exec gosu postgres "$@"
fi

exec "$@"

따라서 재귀 chown은 시작할 때마다 소유권이 있는지 확인한 다음 앱을 사용자로 실행합니다. exec 도 PID 1을 강제 실행하므로 신호가 작동합니다. 그리고 결과 데이터의 컨테이너 외부에서 사용하기 위해 도우미 스크립트와 같은 것으로 볼륨을 채우려면 아마도 도우미 스크립트에도 들어가야 할 것입니다. 그러나 앱이 볼륨에 수많은 파일을 저장하는 경우, 특히 저장소가 로컬이 아닌 경우 컨테이너 시작에 성능 저하가 있는지 여부가 궁금합니다.

더 나은 해결책이 있을 수 있을 것 같습니다. 컨테이너 uid 및 gid를 호스트의 지정된 사용자 이름 및 그룹에 매핑하는 것과 같은 것일 수 있습니다. 도커가 컨테이너의 /etc를 엿보고 이것을 알아낼 수 있습니까?

적어도 퓨즈 없이는 파일 시스템 수준에서 uid/gids를 매핑할 수 없습니다.

적어도 퓨즈 없이는 파일 시스템 수준에서 uid/gids를 매핑할 수 없습니다.

내가 두려워했던 종류. 도커가 이와 같이 퓨즈를 사용하면 성능 저하가 무엇인지 알 수 있습니까?

@mdegans

따라서 매번 시작할 때마다 소유권이 있는지 확인하는 재귀적인 chown,

시작할 때마다 chown 를 할 필요는 없습니다. 대신 데이터 디렉토리의 소유자를 확인하고 올바르지 않은 경우에만 재귀 chown 를 수행하십시오. 이와 같이:

 [ $(stat -c %U "$PG_DATA") == "postgres" ] || chown -R postgres "$PG_DATA"

따라서 이상적으로는 처음 시작할 때만 발생합니다.

그리고 이러한 진입점 스크립트로 컨테이너를 실행할 때는 매우 주의해야 합니다. 홈 디렉토리를 컨테이너에 마운트(예)하면 모든 파일이 postgres에 저장됩니다.

좋은 도커 이미지 디자인에서 런타임 사용자는 루트가 아니므로 chown 파일을 사용할 수 없습니다...!

좋은 도커 이미지 디자인에서 런타임 사용자는 루트가 아니므로 파일을 씹을 수 없습니다...!

맞습니다. 하지만 root 로의 전환을 막는 것은 없어야 합니다. 이는 종종 필요합니다... 필요할 때까지 일반적으로 root 로 아무 것도 실행하지 않아야 하는 것처럼, 그러나 그렇게 할 때 다음 중 하나 이상을 수행할 수 있습니다.

• sudo
• su
• USER root

https://f1.holisticinfosecforwebdevelopers.com/chap03.html#vps -countermeasures-docker-the-default-user-is-root에 따라

내 겸손한 의견으로는 Docker 이미지 사용자가 탑재된 볼륨에 대한 권한을 올바르게 설정했는지 확인하는 것이 중요합니다.

컨테이너가 존재하기 전에 우리가 전통적으로 했던 것과 매우 유사합니다. 예를 들어 nginx를 실행하고 정적 HTML 디렉토리가 올바른 사용자의 소유인지 확인해야 할 때와 같습니다. 내 nginx.conf 파일을 열어야 한다는 것을 알기 위해서는 작업자의 사용자를 확인하고 그에 따라 권한을 설정하십시오. 사실 이것은 모두 nginx 문서에 설명되어 있습니다.

이것은 단지 Unix 권한 문제일 뿐이며 Docker에는 새로운 것이 없습니다. 따라서 이 문제에 대한 해결책은 마운트된 볼륨의 소유권이 되어야 하는 각 Docker 이미지에 대한 더 나은 문서입니다. 디렉토리에 올바른 소유권이 있는지 확인하는 nginx 시작 데몬이 기억나지 않습니다. 올바르게 설정되지 않으면 실패할 뿐입니다.

그러나 이것은 이제 사용자가 잠재적으로 컨테이너 내부에 정의되어 있고 외부에 있지 않기 때문에 사물이 다르게 보이게 하는 것이 사실입니다. 그러나 내부와 외부의 UID는 동일하므로 UID가 2000인 사용자 foobar는 외부가 아니라 컨테이너 내부에 존재할 수 있지만 UID 2000은 여전히 ​​외부의 파일 및 디렉토리에 설정할 수 있습니다. 우리는 우리가 다루던 인간 친화적인 이름보다는 UID/GID의 관점에서 생각을 바꿔야 합니다.
또한 2명의 다른 작성자가 작성한 2개의 컨테이너 간에 볼륨을 공유해야 하는 경우 상황이 더 어려워질 수 있습니다. 기존 Unix 시스템(사용자, 그룹 및 기타)을 사용하여 권한을 설정하는 것만으로는 문제를 해결하기에 충분하지 않을 수 있습니다(공통 UID 또는 GID 없음). Docker를 사용하기 때문에 POSIX ACL을 더 많이 사용하고 있음을 인정합니다. 따라서 동일한 파일에 대해 3명의 다른 사용자 권한을 할당할 수 있습니다. 예를 들어 rw 권한이 있는 컨테이너 작성자, r 권한이 있는 컨테이너 판독기 및 r 권한이 있는 호스트 사용자.

또 하나의 옵션: 공유 디렉토리에 대한 setgid 플래그를 사용하여 공통 GID를 적용할 수 있습니다. ACL을 사용하여 파일 마스크를 적용할 수 있습니다.

Docker 컨테이너에서 작업을 수행하기 전에 다음을 실행하십시오.

```
유마스크 0000
````

https://en.wikipedia.org/wiki/Umask

이 기능이 얼마나 도움이 될 것인지 재확인하기 위해 이 스레드를 늦게 방문합니다.

솔직히 말해서, 저는 약 1년 동안 컨테이너를 배포해 왔으며 이것이 모든 곳에서 실질적인 문제가 되고 있는 것을 봅니다. 여기에서 이 수준에서 솔루션을 제공하는 것이 유일한 현명한 선택인 것 같습니다.

현재로서는 상당한 수의 Docker 이미지가 진입점을 root 로 계속 실행하기로 선택하여 애플리케이션 프로세스를 실행하기 전에 권한을 삭제하기 위해 디렉토리 및 파일 권한을 부트스트랩할 수 있습니다.

모든 사람이 이 관행에 의지할 수 없다는 사실을 깨달을 때 진짜 문제가 나타납니다. Kubernetes 또는 OpenShift와 같은 일부 인기 있는 플랫폼의 경우 이러한 환경 중 일부는 권한 있는 컨테이너를 허용하지 않도록 구성될 수 있습니다. 왜냐하면... 보안 때문입니다. 내 머리로는 어떻게 큰 금융 기관이 이러한 유형의 제한 없이 민감한 정보를 처리하는 컨테이너 플랫폼 채택을 고려하는지 이해할 수 없습니다.

_entrypoint-as-root_ 방식으로 제기된 보안 문제로 인해 애플리케이션 컨테이너가 시작되기 전에 chown 및 chmod 볼륨을 제공할 수 있는 initContainers 를 제공하는 많은 Kubernetes helm 차트가 발생했습니다. . 이것은 좋은 방법처럼 보일 수 있지만 내가 말할 때 저를 믿으십시오. 그렇지 않습니다 .

특히 Helm 차트는 하드코딩된 uids 및 gids 로 가득 차 있습니다. 애플리케이션 런타임에서 비밀리에 추출해야 하기 때문입니다. 해당 정보는 컨테이너 내부에 숨겨져 있으며 배포 중에 즉시 사용할 수 없습니다.

이 문제를 해결하는 방법에는 여러 가지가 있지만 _작동을 위한 해킹_으로 배포 구성 전체를 계속 괴롭히고 있습니다. 이로 인해 영향을 받는 배포 수가 빠르게 증가하고 있으며 사람들이 사용하는 기술은 컨테이너가 제공하는 다른 모든 이점과 상반됩니다.

Docker에 의존하는 다른 솔루션이 이를 사용하여 완전히 자동화된 배포를 우아하게 제공할 수 있도록 OCI 사양의 일부로 이것을 구현하는 방법이 있기를 바랍니다.

따라서 질문은 다음과 같습니다. 인터넷의 다른 곳에서 공통 OCI 사양을 개발하는 곳이 어디입니까? 그것이 이 기능을 도커로 가져오는 가장 좋은 방법이 아니라고 가정합니다(결국 일반적으로 합의된 표준 채택에 대한 요구 사항을 통해).

문제는 확실히 저절로 사라지지 않고 솔루션에는 몇 가지 매우 근본적인 종류의 변경이 필요하기 때문입니다.

응용 프로그램 컨테이너가 시작되기 전에 볼륨을 chown 및 chmod할 수 있는 initContainers. 이것은 좋은 방법처럼 보일 수 있지만 내가 말할 때 나를 믿으십시오. 그렇지 않습니다.

FWIW; 이 기능은 파일이 여러 네임스페이스("호스트"에 존재하는 파일(사전) 또는 다른 사용자로 실행되는 여러 컨테이너 간에 공유되는 공통 파일 위치) 간에 공유되는 상황에서만 필요합니다. 파일이 호스트에서 미리 생성된 상황에서는 파일을 컨테이너와 공유하기 전에 해당 파일에 올바른 소유권과 권한이 있는지 확인하여 이를 완화할 수 있습니다. 실제로 이것은 호스트에서 nginx를 실행하고 webroot의 파일에 올바른 권한이 있는지 확인하는 것과 다르지 않습니다.

다른 사용자로 실행 중인 컨테이너 간에 공유할 때 동일한 uid (또는 gid )로 두 컨테이너를 모두 실행하고 두 개의 컨테이너를 실행할 때 작동하는 방식과 유사한 올바른 그룹 권한을 설정하십시오. 동일한 리소스에 액세스해야 하는 컨테이너화되지 않은 프로세스).

이러한 환경 중 일부는 권한 있는 컨테이너를 허용하지 않도록 구성될 수 있습니다. 왜냐하면... 보안 때문입니다. 내 머리로는 어떻게 큰 금융 기관이 이러한 유형의 제한 없이 민감한 정보를 처리하는 컨테이너 플랫폼 채택을 고려하는지 이해할 수 없습니다.

혼란을 방지하기 위해; root 로 실행되는 컨테이너는 "권한이 있는" 컨테이너와 동일하지 않습니다( --privileged 또는 --cap-add 세트와 같은 옵션). 권한이 있는( --privileged ) 컨테이너는 매우 안전하지 않은 반면 root 로 실행되는 컨테이너는 완전히 포함되어 있어 나갈 수 없습니다 . 바인드 마운트된 파일/디렉토리를 전달하는 것은 구멍을 뚫는 것이므로 바인드 마운트로 전달한 파일/디렉토리에 대한 액세스를 _will_ 제공합니다.

특히 Helm 차트는 애플리케이션 런타임에서 비밀리에 추출해야 하기 때문에 하드코딩된 uid 및 gid로 가득 차 있습니다. 해당 정보는 컨테이너 내부에 숨겨져 있으며 배포 중에 즉시 사용할 수 없습니다.

궁금함: 해당 uid/gid를 알 수 없는 경우 UX는 어떻게 생겼을까요? (호스트 uid/gid를 (알 수 없는) container-uid/gid에 매핑하는 데 사용할 매핑 uid/gid를 제공해야 하기 때문에?

따라서 질문은 다음과 같습니다. 인터넷의 다른 곳에서 공통 OCI 사양을 개발하는 곳이 어디입니까?

(한 눈에) OCI 사양의 변경이 필요하다고 생각하지 않습니다. 이것은 OCI 사양 외부에서 해결할 수 있습니다. 주요 문제는 uid/gids를 매핑하는 메커니즘이 현재 커널에 없다는 것입니다(또는 shiftfs 와 같이 존재하지만 일반적으로 사용할 수 없음).

이것은 책임 이전의 고전적인 오각형입니다 / 다른 사람이 이 문제를 해결할 수 있거나 해결해야 합니다. 다음 중 하나입니다.

• 사용자
• Docker / 컨테이너화 플랫폼의 특정 구현
• OCI 사양
• 핵심
• 파일 시스템

문제는 이미 효과적으로 명시되어 있습니다. 사용자가 이 작업을 수행하는 것은 투박하고 덜 안전하다는 것입니다. 그러나 사용자가 이미지별로 해킹하도록 하는 연쇄 효과도 중요합니다.

즉, 서로 다른 사용자와 함께 작업하기 위해 이미지를 쉽게 상호 운용하고 공유/혼합할 수 없습니다. 그래서 다음 중 하나입니다.

• 커뮤니티 공유를 중단합니다(많이). 서로 다른 사용자가 동일한 전역 네임스페이스 풀에서 개별적으로 개발된 이미지에 대한 uid 및 gid를 정의하기 때문에
• 사용자가 자신만의 임시 표준을 개발하도록 강제하고 다른 사람들이 자신이 선택한 규칙을 따르기를 바랍니다.
• 사용자가 모든 것에 root 를 사용하도록 합니다. 확실히 덜 안전합니다. 다른 방법으로 가질 수 있는 특권 에스컬레이션 보호의 추가 계층을 제거하고 있기 때문입니다. 사용자가 이미 컨테이너 내부에 root 있기 때문에 컨테이너 브레이크아웃 취약점을 훨씬 더 쉽게 악용할 수 있습니다. 같은 컨테이너 내에서 다른 서비스를 실행할 수 있다는 것은 말할 것도 없고 위로 가기 전에 옆으로 가는 또 다른 방법이기도 합니다.

그래서 거래입니다. 위의 것들은 현재 트레이드 오프입니다. 다른 곳에서 위에 나열된 다른 엔터티 중 하나 이상에 책임을 전가하기 위해 다른 절충안이 있는 반면.

파일 시스템 기반 솔루션을 자세히 살펴보는 것과 관련하여 BTW는 스파이더 링크에 대한 이 '잠재적으로 유용할 수 있는' 설명을 발견했습니다.

https://github.com/docker/compose/issues/3270#issuecomment -365644540

여기에는 분산 파일 시스템('Lustre'라고 함) 및 ZFS에 관한 기타 문제를 포함하여 이 동일한 일반 기능(다른 프로젝트/장소에 대한)에 대한 여러 다른 참조가 있습니다. 글쎄, 나는 우연히 여기에서 ZFS를 사용하고 있습니다.

그런 다음 우분투/런치패드에서 동일한 버그의 다른 사본도 찾았습니다. 동일한 ZOL #4177 문제를 참조하여,

https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1567558

문제의 버그가 zfs 버전 0.6.5.7+ SO에서 수정되었다고 말합니다. 이것은 잠재적으로 uid와 gid를 다시 매핑하기 위한 일종의 백업 저장소로 zfs와 ACL을 사용할 수 있음을 의미합니까? 글쎄, 이것은 내가 전에 들어본 것이 아닙니다.

아, 아마도 이 솔루션은 LXC 컨테이너에서만 작동합니다. 그는 거기에 대한 그의 의견(LXC 프로젝트의 리더)에서 "우리는 setuid 도우미(newuidmap 및 newgidmap)를 사용합니다"라고 말했기 때문에 "uid 및 gid 맵을 설정"할 수 있습니다. 따라서 아마도 LXC 자체에 몇 가지 필요한 메커니즘이 있을 것입니다. 그렇지 않으면 zfs acls 부분을 사용할 수 없습니까? 아니면 제가 착각한 것일 수도 있습니다. 나는 이것을 끝까지 따르고 ​​있는지 완전히 확신하지 못합니다.

또 다른 흥미로운 링크, 이번에는 shiftfs 에 대한 링크와 해당 기능을 오버레이에 흡수할 가능성에 대한 토론입니다. 물론 도커가 이미 사용하는 기본 파일 시스템입니다.

그러나 다시 매핑 기능이 overlayfs 로 구현되었지만 기본 파일 시스템 대신 zfs 스토리지 드라이버를 사용하고 싶다면 어떻게 됩니까? 파일 시스템별로 구현되는 경우 uid/gids를 다시 매핑하는 기능에서 제외되어야 합니까? 아니면 둘 다 별도로 구현할 수 있습니까? 죄송합니다. Docker 데몬이 이러한 재매핑을 인식하고 공통 API 및 플래그(fs 드라이버 계층으로 전달하기 위해)를 제공해야 하는지 여부가 약간 불분명합니다. 또는 호스트 측(파일 시스템 내부, 도커 외부)에서 이러한 재매핑을 수동으로 수행하는 경우입니다. 그 부분도 나에게는 조금 불분명하다.

[편집] 앗, 링크를 포함하는 것을 잊었습니다! 여기있어

https://lists.linuxfoundation.org/pipermail/containers/2018-June/039172.html

이 문제는 볼륨/바인드 마운트에 관한 것이므로 컨테이너의 파일 시스템과 별개입니다.

오버레이에 shiftfs 기능이 통합된 경우 bindmount에 대해 uid/gid 시프트와 함께 과도하게 사용하지만 지원되지 않는 시스템에서는 다른 것으로(또는 아무것도) 대체해야 합니다.

Podman은 루트 없는 Docker 드롭인 대체 https://www.youtube.com/watch?v=N0hSn5EwW8w https://podman.io/ 입니다. podman에서는 루트를 사용하지 않으므로 사용자 권한이 올바르게 처리됩니다. 우리 팀은 이 문제로 인해 Podman으로 전환했고 매우 잘 작동했습니다.

이것은 의미가 없습니다.
동일한 문제가 적용됩니다.
docker에는 rootless 모드도 있습니다.

다음 명령어로 Podman을 테스트할 수 있습니다. Podman은 Docker와 달리 별도의 데몬이 없으며 모든 것이 podman 명령을 실행하는 사용자 아래에서 실행됩니다. 따라서 podman 내부에 생성된 파일은 podman run ... 명령을 실행한 사용자가 소유합니다.

kkimdev<strong i="8">@ubuntu</strong>:~$ mkdir podman_test
kkimdev<strong i="9">@ubuntu</strong>:~$ ls -agh podman_test
total 8.0K
drwxrwxr-x 2 kkimdev 4.0K Jun 27 04:23 .
drwxr-xr-x 8 kkimdev 4.0K Jun 27 04:23 ..

kkimdev<strong i="10">@ubuntu</strong>:~$ podman run --rm -it -v ~/podman_test:/podman_test alpine
/ # cd /podman_test/
/podman_test # touch test_file
/podman_test # ls -agh
total 8K
drwxrwxr-x    2 root        4.0K Jun 27 02:24 .
drwxr-xr-x   20 root        4.0K Jun 27 02:24 ..
-rw-r--r--    1 root           0 Jun 27 02:24 test_file

/podman_test #

kkimdev<strong i="11">@ubuntu</strong>:~$ ls -agh podman_test/
total 8.0K
drwxrwxr-x 2 kkimdev 4.0K Jun 27 04:24 .
drwxr-xr-x 8 kkimdev 4.0K Jun 27 04:23 ..
-rw-r--r-- 1 kkimdev    0 Jun 27 04:24 test_file

이것은 podman 에 대해 광고하기에 적절한 장소가 아닙니다. 이 문제를 해결하는 데 도움이 될 수 있는 작동 방식에 대한 구체적인 기술 세부정보가 있는 경우 특히 해당 문제에 대한 잠재적인 솔루션으로 논의할 수 있습니다. 현재 댓글을 다시고 있습니다. 지금까지는 이것이 아니므로 이 논의를 다른 곳에서 진행하십시오.

podman 가 Docker와 아키텍처가 매우 다르기 때문에 이 문제를 덜 심각하고 고통스럽게 만든다고 해서 Docker가 이 한 가지 문제를 해결하기 위해 작동 방식을 완전히 변경할 수 있는 것은 아닙니다. Docker가 있는 그대로 구성되어 있는 데에는 여러 가지 이유가 있으며 이러한 모든 기록을 무시하는 것은 솔직히 잘못된 생각입니다.

@tianon 예, 두 가지 접근 방식 모두 장단점이 있습니다. 대상 사용자와 함께 컨테이너를 podman으로 실행하면 이 기술적인 문제, 즉 "루트가 아닌 사용자로 볼륨 탑재"가 특히 해결되기 때문에 podman을 언급했습니다.

위 댓글에 생성된 "test_file"의 권한을 확인해주세요. 먼저 "~/podman_test" 디렉토리를 마운트하고 podman 컨테이너 내부에 "test_file" 파일을 씁니다. 그런 다음 사용자가 컨테이너 외부로 이동하면 파일이 루트가 아닌 "kkimdev"의 소유임을 알 수 있습니다.

문제는 Docker 문제를 해결하기 위한 귀하의 제안이 Docker용 문제 추적기에서 크게 건설적이지 않은 "Docker를 사용하지 않음"에 해당한다는 것입니다.

예, podman 는 다르게 설계되어 이 문제가 해당 도구에 대해 무의미합니다. 훌륭하고 괜찮지만 여기서는 주제에서 완전히 벗어났습니다. Rootless에는 서로 다른 장단점이 있으며, 그 중 일부는 일부 사람들에게 적합하고 일부는 그렇지 않습니다. 시간이 지남에 따라(대부분 커널 개선) 개선되고 있지만 여기 있는 모든 사람을 위한 일반적인 솔루션은 아닙니다.

이를 위해서는 위에서 자세히 논의한 바와 같이 일반 솔루션을 위한 커널 수정 또는 shim이 필요합니다( @cpuguy83 및 다른 사람들이 일반적인 방식으로 이 문제를 해결하는 데 도움을 주기 위해 노력하고 있음).

Docker는 2013년부터 이 특정 문제를 공개했으며 거의 ​​6년이 지난 후에도 쉽게 개선되지 않습니다. Podman은 Docker와의 호환성을 확보하지만 Docker의 설계 결함도 해결하도록 설계되었습니다(수퍼유저 Docker 데몬이 필요하지 않은 권한 없는 사용자로 실행 포함).

사용자가 GitHub 문제에 대해 다른 사람에게 조언을 줄 수 있다면 전혀 문제가 없습니다. 이것은 커뮤니티입니다. 도움이 될만한 것을 자유롭게 추천하십시오.

Docker가 있는 그대로 구성되어 있는 데에는 여러 가지 이유가 있음을 장담할 수 있습니다.

grep 도 마찬가지입니다. 그러나 누군가 더 빠르게 검색해야 하는 경우 여전히 ripgrep 을 권장합니다. grep 이슈 트래커에서도 말이죠. 사용자의 문제를 해결하고 사용자를 행복하게 하는 한 문제 추적기가 누구의 문제인지는 중요하지 않습니다.

Podman이 작동하지 않는 경우: 좋습니다! 하지만 인프라에서 docker 를 podman 로 바꿔야 하기 때문에 다른 사람들에게 도움이 된다면 그냥 그렇게 하도록 내버려 두십시오.

Podmans의 주요 주장은 데몬을 실행하지 않는다는 것이며 이것이 이에 대한 저의 주요 주장입니다. 재부팅 후 컨테이너를 어떻게 백업합니까? 나는 그것을 손으로하지 않을 것이고 다른 모든 것은 단지 나쁜 디자인 일뿐입니다. 또한 사용자가 소유하지만 시스템이 소유한 도커 컨테이너를 원하지 않으며 이는 루트를 의미합니다.
당신이 그것을 사용하는 유일한 사람이라면 Podman이 의미가 있습니다.

그리고 문제를 해결하려면 COPY --chown ...:... 로 컨테이너를 빌드하세요!

또한 도커에는 그런 문제 가 없으며 나에게도 중요한 도커 서버를 원격으로 제어할 수 있습니다.

실행 중인 컨테이너에서 포드를 생성하는 도구도 있지만 처음부터 깨끗한 방식으로 빌드해야 하므로 권장하지 않습니다.

이제 주제로 돌아가야 할 것 같습니다. IMHO의 첫 번째 조언은 괜찮았지만 다른 모든 것은 이 문제를 날려버리고 아무 것도 해결하지 못합니다.

재부팅 후 컨테이너를 어떻게 백업합니까? 나는 그것을 손으로하지 않을 것이고 다른 모든 것은 단지 나쁜 디자인 일뿐입니다.

글쎄요, Podman은 systemd와 기본적으로 통합되어 있습니다 (거의 모든 최신 GNU Linux 배포판에서 _거의_ 다른 모든 것). 따라서 '두 개의' 부팅 시스템을 유지할 필요가 없습니다(예: 먼저 Docker 데몬을 시작하기 위해 systemd를 실행한 다음 다른 구성에서 시작 컨테이너의 또 다른 라운드를 만들어야 함). 따라서 Podman을 사용하면 systemd로 모든 것을 제어할 수 있습니다(즉, 이미 설치되어 실행 중일 가능성이 높은 시스템).

또한 사용자가 소유하지만 시스템이 소유한 도커 컨테이너를 원하지 않으며 이는 루트를 의미합니다.

당신이 그것을 원하지 않는다면 그것은 완전히 괜찮습니다. 여전히 수퍼유저로 Podman을 실행할 수 있지만 더 이상 _하지 않아도 됩니다. 일반적으로 누군가가 Docker 데몬을 악용할 수 있는 경우 시스템의 _모든 것_에 대한 제어 권한이 있기 때문에 이는 나쁜 생각으로 간주되고 공격 표면을 증가시킵니다.

당신이 그것을 사용하는 유일한 사람이라면 Podman이 의미가 있습니다.

이 진술은 의미가 없습니다. Podman을 사용하면 단일 시스템에 분산할 수 있습니다. 이는 동일한 시스템에서 많은 사람들이 작업하는 경우 특히 적합한 기능입니다.

그리고 문제를 해결하려면 COPY --chown ...:... 로 컨테이너를 빌드하세요!

여기서 문제는 _runtime_의 컨테이너에 대한 볼륨을 _mounting_하는 것입니다. 이미지 구축과 거의 관련이 없습니다.

또한 도커에는 그런 문제 가 없으며 나에게도 중요한 도커 서버를 원격으로 제어할 수 있습니다.

이 게시물이 있는 블로그를 정확히 언급하는 것이 재미있습니다. 그러나 나는 두 구현의 네트워크 세부 사항에 대해 경험이 많지 않지만 내가 이해한 바와 같이 podman은 가능한 최소 네트워크 규칙으로 시작하고 권한이 없는 사용자는 veth 쌍을 설정할 수 없습니다.

분명히 하자면, podman에서 얻을 수 있는 것과 같은 효과를 rootless docker에서도 얻을 수 있어야 합니다.
dockerd가 사용자로 실행되고 컨테이너의 루트가 UID에 매핑되기 때문입니다.

이것은 단점이 있으며 물론 여러 사용자와 데몬을 공유할 때는 작동하지 않습니다.
https://get.docker.com/rootless

2019년 6월 27일 오전 7시 52분에 Alexander Adam [email protected] 이 다음과 같이 썼습니다.

이제 주제로 돌아가야 할 것 같습니다. IMHO의 첫 번째 조언은 괜찮았지만 다른 모든 것은 이 문제를 날려버리고 아무 것도 해결하지 못합니다.

@SuperSandro2000 https://github.com/SuperSandro2000 , 하지만 여기를 클릭하면 귀하의 진술에 대한 답변을 볼 수 있습니다.
https://podman.io/blogs/2018/09/13/systemd.html https://osric.com/chris/accidental-developer/2018/12/docker-versus-podman-and-iptables/ https:/ /osric.com/chris/accidental-developer/2018/12/using-docker-to-get-root-access/
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
직접이 이메일에 회신 볼을 GitHub의에 https://github.com/moby/moby/issues/2259?email_source=notifications&email_token=AAGDCZXX2UQCG7LUVH57V6LP4TH2DA5CNFSM4AI3DP62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYXL2XI#issuecomment-506379613 , 또는 스레드 음소거 https://github.com/notifications/을 unsubscribe-auth/AAGDCZX437HJP4M6XG3SEY3P4TH2DANCNFSM4AI3DP6Q .

@alexanderadam

IMHO 여기서 문제는 런타임에 컨테이너에 대한 볼륨을 탑재하는 것입니다. 이미지 구축과 거의 관련이 없습니다.

내 솔루션은 디렉토리를 마운트하지 않고 가능한 경우 컨테이너에 굽는 것입니다.

내 말은 podman이 좋은 것처럼 들리지만 지금은 이유를 바꾸지 않을 것입니다. 암튼 설명 감사합니다.

podman 컨테이너 내부의 Apache가 www 사용자로 실행되는 경우에도 동일한 문제가 발생합니다. https://github.com/containers/libpod/issues/3990

솔루션은 컨테이너 내부에 root 사용자가 없는 경우 컨테이너에서 호스트의 UID로 www 사용자를 매핑하는 것일 수 있습니다. 그게 가능한지 모르겠습니다.

--read-only 로 실행하고 싶다면( readOnlyRootFilesystem Kubernetes 정책과 동일하게 하기 위해) 아래와 같이 하면 됩니다. @jpetazzo 가 제안한 해결 방법을 기반으로 합니다.

• 내 도커 이미지는 uid=1001 및 gid=1001인 사용자를 만들고 사용합니다.
• 별도로 도커 볼륨 생성
• uid:gid 를 1001로 설정
• 응용 프로그램을 실행할 때 해당 이미지를 탑재합니다.

도커 파일:

FROM ubuntu

RUN groupadd -g 1001 appgroup && \
    useradd -u 1001 -g appgroup appuser

USER appuser

그 다음에:

$ docker build . -t test
$ docker volume create somedir
$ docker run -v somedir:/some_dir alpine chown -R 1001:1001 /some_dir

이제 도커 이미지를 실행하고 볼륨을 마운트할 때 /some_dir은 내가 원하는 사용자의 것입니다.

$ docker run -it --read-only -v somedir:/some_dir test ls -lrt

...
dr-xr-xr-x  13 root    root        0 Nov  4 15:22 sys
drwxr-xr-x   2 appuser appgroup 4096 Nov  5 09:45 some_dir
drwxr-xr-x   1 root    root     4096 Nov  5 09:45 etc
...

$ docker run -it --read-only -v somedir:/some_dir test touch /some_dir/hello
$ docker run -it --read-only -v somedir:/some_dir test ls -lrt /some_dir

-rw-r--r-- 1 appuser appgroup 0 Nov  5 09:52 hello

스레드에서 쉽게 손실되기 때문에 chown된 symlink가 대부분의 시나리오에서 작동할 것이라는 점을 다시 한 번 지적하겠습니다. 단점은 설정이 필요하다는 것인데, 이는 종종 진입점을 원래 명령을 실행하는 스크립트로 대체하는 것을 의미합니다.

https://github.com/moby/moby/issues/2259#issuecomment -466094263

+1

나는 이것이 지금까지 내가 도커에 대해 가지고 있는 가장 성가신 문제라고 생각하고 이것이 이미 열려 있는 시간을 보면 이것이 다른 많은 사람들에게는 해당되지 않는다는 것을 암시합니까?

해결 방법을 알고 있으면 문제가 되지 않습니다. 내 경우:

• 호스트는 리눅스

  • 컨테이너의 uid == 호스트의 원하는 uid - 해결 방법이 필요하지 않습니다.
  • 컨테이너의 uid != 호스트에서 원하는 uid - 몇 가지 setfacl 명령을 실행하고 호스트 사용자와 컨테이너 사용자 모두에게 rw 액세스 권한을 부여하십시오.

• 호스트는 MacOS입니다. 모든 것이 공식 Docker 앱에서 즉시 사용할 수 있습니다.

몇 개의 setfacl 명령을 실행하고 호스트 사용자와 컨테이너 사용자 모두에게 rw 액세스 권한을 부여하십시오.

이것은 문제예요. 모든 도커 이미지에 대해 몇 가지 setfacl 명령 을 실행하고 OS를 감지하고 싶지 않습니다.

이것은 실제로 큰 보안 문제이기도 합니다.

예시 시나리오:

• host1 에 도커가 설치되어 있습니다.
• host1 에는 도커 컨테이너에서 실행되는 여러 서비스가 있습니다. 모두 /docker/my-service-01|02|03|etc 아래의 마운트 로컬 경로입니다.
• 각 컨테이너는 다른 공급업체에서 제작했으며 각 컨테이너는 자체 uid 및 guid 정책을 따르므로 그에 따라 chown -R uid.gid /docker/my-service-01... 를 요구합니다.

결과:

• host 에 생성된 일반 또는 서비스 사용자는 언젠가는 의도하지도 원하지도 않은 /docker/my-service-01|02|03|etc 에 대한 전체 액세스 권한을 갖게 됩니다.
• 볼륨을 다른 공급업체의 두 컨테이너에 "읽기 전용"으로 탑재하려는 경우 - uid.gid 이 필수 항목과 일치하지 않고 chown 를 사용할 수 없기 때문에 실패합니다. uid.gid 정책이 있고 서로 다르기 때문입니다. :)

예, 우리는 이전에 이 문제에 대해 길게 논의했으며 (당시) 다시 전달되는 핵심 사실은 Linux 커널에 재매핑 가능한 uid 및 gid를 제공하는 기본 지원 메커니즘이 없다는 것이었습니다. 따라서 이 프로젝트(moby/docker)가 매우 바람직한 기능을 구현하려면 커널에 추가해야 합니다. 그렇지 않으면 우리는 이미 이 기능을 얼마 전에 얻었을 것입니다. 처음 봤을 때로 돌아간다.

따라서 (오늘) 이 토론을 계속하는 가장 생산적인 방법은 다음과 같습니다. 그 이후로 변경된 상황이 있는지 확인합니다. vger.org에서 linux kernel mainline devs의 기술 논평을 찾으십시오. 이 기본 누락 기능에 대한 커널의 과거 패치 세트/병합 요청을 찾으십시오. 등.

그 낮은 수준에서 무슨 일이 일어나고 있는지 더 잘 이해하기를 바랍니다. 걸림돌은 무엇이었습니까? 성능 문제였나요? 보안 모델/약화 측면에서 반대였습니까? 아직 테이블이나 미래 로드맵에 있지만 다른 기능 B와 C를 구현할 수 있어야만 의미가 있습니까? 이 모든 커널 개발은 다른 곳에서 진행됩니다. 다른 채널에서.

@DXist 이것이 Linux가 아닌 OSX에서 마술처럼 작동한다는 사실은 놀랍고 그 자체로 문제입니다.

@dreamcat4 님의 마지막 댓글에 따르면, 이 상태가 어떤지 새로운 시도를 한 사람이 있습니까? 지금 커널에서 다시 매핑 가능한 uid 및 gid를 지원합니까? 전반적인 상태는 어떻습니까?

이 문제를 완벽하게 해결하기 위해 Linux 사용자 네임스페이스를 사용했습니다. 다른 플랫폼과 정확히 동일(AFAICT) 작동합니다(컨테이너는 마운트된 볼륨을 루트로 보고, 호스트는 도커를 실행하는 사용자로 봅니다).

가이드는 여기: https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-remap/

@패트로빈슨 +1