Дозволи користувача всередині та поза контейнерами 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 - це те, що вам потрібно .

Довга відповідь: Так як у вашому прикладі є контейнер з ім'ям док з об'ємом /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 в контейнері .