Подчиненные GIDs / UID с LXC и для непривилегированного пользователя?

При использовании userns (через LXC в моем случае) вы назначаете диапазон подчиненных GID и UID неприемлемому пользователю. См. Ресурсы: subuid(5) , subgid(5) , newuidmap(1) , newgidmap(1) , user_namespaces(7) .

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

Предположим, что у нас есть (хост) системная учетная запись john с UID (и GID) 1000. Назначенный диапазон GID и UID – 100000..165536.

Таким образом, запись существует в /etc/subgid и /etc/subuid соответственно:

 john:100000:65536 

Файлы, находящиеся в непривилегированном контейнере, принадлежат «внутри» john , теперь будут принадлежать 101000 на хосте, а владельцы root «внутри» будут принадлежать 100 000.

Обычно эти диапазоны не назначаются ни одному имени на хосте.

Вопросов:

  1. правильно ли создать пользователя для этих UID / GID на хосте, чтобы иметь более значимый вывод для друзей и друзей?
  2. есть ли способ сделать эти файлы / папку доступными для хост-пользователя, который «владеет» userns, то есть john в нашем случае? И если это так, является единственным разумным методом для создания группы, разделяемой между теми действительными пользователями внутри подчиненного диапазона и владельцем «владельцев» и соответствующим образом заданными разрешениями? Ну, или ACL, очевидно.

One Solution collect form web for “Подчиненные GIDs / UID с LXC и для непривилегированного пользователя?”

  1. Можно ли создать пользователя для этих UID / GID на хосте, чтобы иметь более значимый результат для друзей и друзей?

Да, все в порядке. Однако вы должны убедиться, что такой пользователь не имеет права ни на что в хост-системе:

  • Доступ для инвалидов или пароль,
  • Нет пригодной для использования оболочки входа,
  • Невозможно записать домашний каталог.

Не забудьте также создать дубликат в ваших именах пользователей.

Ниже приведен пример сценария, в котором файлы /etc/passwd и /etc/group гостя создаются соответствующими пользователями в главной системе. Все имена имеют префикс имени контейнера, и все идентификаторы увеличены с использованием заданного значения для соответствия UID контейнера:

 #! /bin/sh # Path to guest's `/etc' directory. guest_etc=/var/lib/lxc/mycontainer/rootfs/etc # Guest's name, used as login prefix and inside GECOS field. guest_name=mycontainer # Increment to be applied to UIDs and GIDs (= range start). uid_incr=100000 gid_incr=$uid_incr guest_passwd=${guest_etc}/passwd guest_group=${guest_etc}/group exec <$guest_group while IFS=":" read name pass gid null; do gid_new=$( expr $gid + $gid_incr ) if ! getent group $gid_new >/dev/null; then addgroup --system --gid $gid_new "${guest_name}_${name}" fi done exec <$guest_passwd while IFS=":" read login pass uid gid gecos null; do uid_new=$( expr $uid + $uid_incr ) gid_new=$( expr $gid + $gid_incr ) if ! getent passwd $uid_new >/dev/null; then adduser --system --home /nonexistent --no-create-home \ --shell /bin/nologin --uid $uid_new --gid $gid_new \ --gecos "\"$guest_name container user (${gecos})\"" \ "${guest_name}_${login}" fi done системы #! /bin/sh # Path to guest's `/etc' directory. guest_etc=/var/lib/lxc/mycontainer/rootfs/etc # Guest's name, used as login prefix and inside GECOS field. guest_name=mycontainer # Increment to be applied to UIDs and GIDs (= range start). uid_incr=100000 gid_incr=$uid_incr guest_passwd=${guest_etc}/passwd guest_group=${guest_etc}/group exec <$guest_group while IFS=":" read name pass gid null; do gid_new=$( expr $gid + $gid_incr ) if ! getent group $gid_new >/dev/null; then addgroup --system --gid $gid_new "${guest_name}_${name}" fi done exec <$guest_passwd while IFS=":" read login pass uid gid gecos null; do uid_new=$( expr $uid + $uid_incr ) gid_new=$( expr $gid + $gid_incr ) if ! getent passwd $uid_new >/dev/null; then adduser --system --home /nonexistent --no-create-home \ --shell /bin/nologin --uid $uid_new --gid $gid_new \ --gecos "\"$guest_name container user (${gecos})\"" \ "${guest_name}_${login}" fi done и #! /bin/sh # Path to guest's `/etc' directory. guest_etc=/var/lib/lxc/mycontainer/rootfs/etc # Guest's name, used as login prefix and inside GECOS field. guest_name=mycontainer # Increment to be applied to UIDs and GIDs (= range start). uid_incr=100000 gid_incr=$uid_incr guest_passwd=${guest_etc}/passwd guest_group=${guest_etc}/group exec <$guest_group while IFS=":" read name pass gid null; do gid_new=$( expr $gid + $gid_incr ) if ! getent group $gid_new >/dev/null; then addgroup --system --gid $gid_new "${guest_name}_${name}" fi done exec <$guest_passwd while IFS=":" read login pass uid gid gecos null; do uid_new=$( expr $uid + $uid_incr ) gid_new=$( expr $gid + $gid_incr ) if ! getent passwd $uid_new >/dev/null; then adduser --system --home /nonexistent --no-create-home \ --shell /bin/nologin --uid $uid_new --gid $gid_new \ --gecos "\"$guest_name container user (${gecos})\"" \ "${guest_name}_${login}" fi done 

Предупреждения относительно недоступного домашнего каталога являются нормальными и ожидаемыми: это фактическая цель /nonexistent чтобы не существовать.

  1. есть ли способ сделать эти файлы / папку доступными для хост-пользователя, который «владеет» userns, то есть john в нашем случае? И если это так, является единственным разумным методом для создания группы, разделяемой между теми действительными пользователями внутри подчиненного диапазона и владельцем «владельцев» и соответствующим образом заданными разрешениями? Ну, или ACL, очевидно.

Это должно стоить отдельного вопроса ИМО.

Поскольку содержимое контейнера принадлежит различным UID, чем UID владельца контейнера, тогда он недоступен для него. Я могу представить себе исключение из этого правила для подчиненных, но в настоящее время я не знаю (я создал связанный вопрос несколько раз назад, но ответа еще нет).

Файлы /etc/subuid и /etc/subgid в настоящее время используются только newuidmap (1), чтобы разрешить или запретить переход с одного UID / GID на другой из данного процесса. Это не дает владельцу диапазона никакого другого права.

Поэтому решение такой проблемы должно разрабатываться в каждом конкретном случае. Опасайтесь, однако, с идеей ACL: допустим, вы добавили некоторые файлы ACL в файлы контейнера, чтобы позволить UID 1000 вашего хоста читать их, это означает, что пользователь контейнера с UID 1000 контейнера также будет иметь тот же уровень привилегий …

  • контейнер userns не запускается, как отслеживать причину?
  • Что делает firefox внутри контейнера запускает новое окно firefox снаружи на хосте с UID хост-пользователя? Разве это не странно для LXC?
  • Не удается подключиться к sshd у моего непривилегированного гостя LXC. Что делать?
  • Linux и Unix - лучшая ОС в мире.