Права пользователя внутри и снаружи контейнеров LXC?

Я запускаю некоторые сервисы внутри контейнеров Docker LXC на моем сервере, и я начинаю делать с ними серьезные вещи.

Одна вещь, которая мне не ясна - это то, как пользовательские разрешения работают внутри и снаружи контейнера. Если, например, я запускаю MySQL в контейнере и для его каталога данных установлено значение /data, то есть том Docker, как разрешения внутри и снаружи контейнера влияют на политики доступа?

Очевидно, что идея состоит в том, чтобы запустить MySQL как своего собственного пользователя в контейнере (т.е. mysql:mysql) и дать ему права на чтение и запись в этот каталог. Я предполагаю, что это было бы довольно просто, просто с chmodпомощью каталога и т. Д. Но как это работает вне контейнера? Теперь, когда у меня есть общий том Docker под названием «данные», как мне управлять доступом к нему?

Я специально ищу возможность запустить непривилегированного пользователя вне контейнера Docker, который будет периодически получать доступ к общему объему MySQL и делать резервные копии данных.

Как настроить разрешения, пользователей и группы, чтобы конкретный пользователь на хосте мог читать / записывать файлы и папки на общем томе Docker?

С момента выхода 0.9 Docker прекратил работу LXCи использует собственную среду исполнения libcontainer. Ваш вопрос немного устарел, но я думаю, что мой ответ по-прежнему относится к версии, которую вы используете

Быстрый ответ: Чтобы понять разрешения томов, вы можете взять аналогию mount --bind Host-Dir Container-Dir. Таким образом, для выполнения ваших требований вы можете использовать любые традиционные методы управления разрешениями. Я думаю, ACL - это то, что вам нужно .

Длинный ответ: Как и в вашем примере, у нас есть контейнер с именем dock и томом /data.

docker run -tid --name dock -v /usr/container/Databases/:/data \
    centos:latest /bin/bash

Внутри контейнера наш сервер MySQL был настроен для использования в /dataкачестве своего каталога данных. Таким образом, у нас есть наши базы данных /dataвнутри контейнера. За пределами контейнера в ОС хоста мы смонтировали этот /dataтом с /usr/container/Databases/и назначаем обычного пользователя bob для создания резервных копий баз данных. С хост-машины мы настроим ACL для пользователя bob .

useradd -u 3000 bob
usermod -R o=--- /usr/container/Databases/
setfacl -R -m u:bob:rwx /usr/container/Databases/
setfacl -R -d -m u:bob:rwx /usr/container/Databases/

Чтобы проверить это, давайте сделаем резервную копию с пользователем bob .

su - bob
tar -cvf container-data.tar /usr/container/Databases/

И tar выдаст список, и вы увидите, что наш пользователь смог получить доступ ко всем файлам.

Теперь изнутри контейнера, если вы проверите с ним, getfaclвы заметите, что вместо bob он показывает 3000. Это потому, что UID bob равен 3000 и такого пользователя в контейнере нет, поэтому он просто отображает UID, который он получает из метаданных , Теперь, если вы создадите пользователя в своем контейнере, useradd -u 3000 bobвы заметите, что теперь getfaclотображается имя bob вместо 3000.

Сводка . Таким образом, пользовательские разрешения, которые вы назначаете изнутри или снаружи контейнера, отражают обе среды. Поэтому для управления разрешениями томов идентификаторы UID на хост-компьютере должны отличаться от идентификаторов UID в контейнере .