Рассмотрим следующий тривиальный файл Docker:
FROM debian:testing
RUN adduser --disabled-password --gecos '' docker
RUN adduser --disabled-password --gecos '' bob
в рабочем каталоге ни с чем другим. Создайте изображение докера:
docker build -t test .
а затем запустите в контейнере bash script, связав рабочий каталог с новым поддиректором в домашнем каталоге bob:
docker run --rm -it -v $(pwd):/home/bob/subdir test
Кому принадлежит содержимое subdir на контейнере? На контейнере запустите:
cd /home/bob/subdir
ls -l
ad мы видим:
-rw-rw-r-- 1 docker docker 120 Oct 22 03:47 Dockerfile
Святые курят! docker владеет содержимым! Вернемся на главную машину за пределами контейнера, мы видим, что наш оригинальный пользователь все еще владеет Dockerfile. Попробуйте исправить право собственности на домашний каталог bob. На контейнере запустите:
chown -R bob:bob /home/bob
ls -l
и мы видим:
-rw-rw-r-- 1 bob bob 120 Oct 22 03:47 Dockerfile
Но подождите! вне контейнера, теперь мы запускаем ls -l
-rw-rw-r-- 1 1001 1001 120 Oct 21 20:47 Dockerfile
у нас больше нет собственного файла. Ужасные новости!
Если бы в приведенном выше примере был добавлен только один пользователь, все было бы более гладко. По какой-то причине Docker, похоже, создает любой домашний каталог, принадлежащий первому пользователю без полномочий root, который он встречает (даже если этот пользователь объявлен на более раннем изображении). Аналогично, этот первый пользователь является тем, который соответствует тем же правам на доступ, что и мой домашний пользователь.
Вопрос 1 Это правильно? Может кто-то указать мне на документацию, я просто предполагаю, основываясь на вышеупомянутом эксперименте.
Вопрос 2. Возможно, это связано только с тем, что оба они имеют одинаковое числовое значение в ядре, и если я тестировал систему, где мой домашний пользователь не был id 1000, то разрешения могли бы получить изменено в каждом случае?
Вопрос 3. Реальный вопрос, конечно, "что мне делать с этим?" Если bob зарегистрирован как bob на данном хост-компьютере, он должен иметь возможность запускать контейнер как bob и не изменять файлы в своей учетной записи хоста. Как бы то ни было, ему действительно нужно запустить контейнер как пользователь docker, чтобы избежать изменения его учетной записи.
Я слышал, вы спрашиваете, почему у меня такой странный Dockerfile? Иногда я удивляюсь. Я пишу контейнер для webapp (RStudio-server), который позволяет другим пользователям регистрироваться, что просто использует имена пользователей и учетные данные с Linux-машины в качестве допустимых имен пользователей. Это приносит мне, возможно, необычную мотивацию желать создать несколько пользователей. Я могу обойти это, создав пользователя только во время выполнения, и все в порядке. Тем не менее, я использую базовое изображение, которое добавило единственного пользователя docker, чтобы его можно было использовать в интерактивном режиме, но не выполнялось как root (согласно наилучшей практике). Это разрушает все, поскольку этот пользователь становится первым пользователем и заканчивает тем, что владеет всем, поэтому попытки входа в систему по мере того, как другие пользователи терпят неудачу (приложение не может запускаться из-за отсутствия разрешений на запись). При запуске script run chown сначала решается эта проблема, но ценой связанных томов, изменяющих разрешения (очевидно, только проблема, если мы связываем тома).
