Мой / etc / subuid был sullivan: 100000: 65536, и удаление двух лишних 0 сделало трюки. Но в чем разница? Есть ли побочные эффекты от нашей ОС? Не могли бы вы объяснить немного @Xinity?

буюuserns-переназначить особенность Docker для создания файла внутри контейнера какroot пользователь и владелец этого файла какtest Пользователь на хосте.

Я добавил следующее к/etc/docker/daemon.json

{
  "userns-remap": "test:test"
}

Похоже, что переназначение произошло на основе логов демона.

User namespaces: ID ranges will be mapped to subuid/subgid ranges of: test:test

и записиtest:100000:65536 а такжеtest:100000:65536 были добавлены в/etc/subuid а также/etc/subgid/ файлы соответственно.

Но когда я запускаю контейнер и пытаюсь создать файл в рабочем каталоге, происходит сбой

test@box:~$ docker run -v /home/test/tmp:/somedir -w /somedir -it ubuntu:16.04 /bin/bash
root@11ff6c42ffe1:/somedir# touch file.txt
touch: cannot touch 'file.txt': Permission denied

root@11ff6c42ffe1:/somedir# ls -l
total 0
-rw-rw-r-- 1 nobody nogroup 0 Mar 23 21:39 already_existing_file.txt

root@11ff6c42ffe1:/somedir# id root
uid=0(root) gid=0(root) groups=0(root)

root@11ff6c42ffe1:/somedir# touch /file.txt

Создание файла в каком-то другом каталоге, который не смонтирован с хоста, работает как положено.

Кроме того, если разрешение 777 предоставлено подключенному каталогу, в этом случае/ Главная / тест / TMP на хосте файл может быть успешно создан изнутри контейнера. Однако недавно созданный файл имеет следующие разрешения на хосте:

ls -l /home/test/tmp
total 0
-rw-r--r-- 1 165536 165536 0 march 29 01:36 file.txt 

Пользователь с идентификатором 165536 отсутствует в / etc / passwd, что возвращает нас к началу. Я ожидаю, чтокорень Пользователь внутри контейнера имеет те же права, что иконтрольная работа пользователь на хосте и что файлы, созданныекорень У пользователя в контейнере есть владелец на хосте, который отображается с помощью userns-remap, т.е.контрольная работа.

Это указано вдокументы это

... если тома монтируются с хоста, владение файлом должно быть предварительно организовано, чтобы иметь право на чтение или запись содержимого тома.

... Одним заметным ограничением является невозможность использования команды mknod. Отказано в создании устройства в контейнере при запуске пользователем root.

Значит ли это, чтокорень Пользователь внутри контейнера не может создавать файлы / каталоги внутри подключенного каталога, даже если владельцем подключенного каталога является пользователь, которыйкорень сопоставляется с использованием userns-remap, в этом случаеконтрольная работа?

Любые идеи, как сделать рабочий каталог также доступным для записи пользователем внутри контейнера?

Версия докера: 18.03.0
Версия Ubuntu: 16.04.1
Версия ядра: 4.13.0-36-generic

Действия по воспроизведению

sudo adduser test
sudo usermod -aG docker test
sudo echo '{ "userns-remap": "test"}' >> /etc/docker/daemon.json
service docker restart
su - test
mkdir tmp
docker run -v /home/test/tmp:/somedir ubuntu:16.04 touch /somedir/file.txt

Вот некоторые похожие вопросы, но не совсем такие, как я хотел бы сделать эту работубез изменение Dockerfile:

Docker и --userns-remap, как управлять разрешениями для томов для обмена данными между хостом и контейнером? - именно то, что задается в этом вопросе, но ответа не было в течение 2 лет, поэтому этот вопрос остается открытымразрешения для присоединения без монтирования в докере, WITH --userns-remapМогу ли я управлять владельцем тома, привязанного к привязке, в образе докера?Docker не может записывать в каталог, смонтированный с помощью -v, если у него нет разрешений 777

Ответы на вопрос(1)

Ваш ответ на вопрос