LINUX.ORG.RU
ФорумAdmin

(решено) cannot create /dev/null: Permission denied в LXC контейнере

 , , , ,


0

1

Столкнулся с багой, с ходу аналогичные кейсы не нагуглились, пришлось думать самому. Напишу здесь отчёт, глядишь кому-то пригодится.
Конфигурация:
Хост-система debian jessie, LXC 1.0.6 из штатного репозитория.
В контейнере debian stretch (текущий testing, установлен через lxc-create с помощью подредактированного шаблона (стандартный шаблон не даёт создавать контейнер из тестинга), впрочем дело не в этом). В конфиге контейнера lxc.autodev = 1.
В хост-системе заданна не стандартная (для debian) umask 0027 (через соответствующий параметр в /etc/login.defs и session optional pam_umask.so в /etc/pam.d/common-session).

После запуска контейнера директория /dev в контейнере имеет права 750 (вместо привычных 755), что мешает жить некоторым программам, в частности mysqld выдаёт ошибку вынесенную в заголовок.

Учитывая вводную причина проблемы очевидна: lxc-start запуская контейнер создаёт для него директорию /dev, создавая директорию lxc-start использует umask из окружения в котором он запущен, ?????, директория создаётся с правами 750.

Возможные решения:
* Отказаться от использования «нестандартного» umask в хост-системе.
* Перед запуском контейнера вручную менять umask текущей сессии на более либеральный.
* Воткнуть в lxc костыль задающий нужные права на директорию в процессе запуска контейнера. lxc.hook.autodev в помощь.
* Воткнуть костыль в сам контейнер.

★★★★★

В хост-системе заданна не стандартная (для debian) umask 0027

А в чем причина такого изуверства?

Radjah ★★★★★ ()
Ответ на: комментарий от Radjah

Как по мне так это должно быть дефолтом, и в некоторых дистрах это действительно так. Что не разрешено, то запрещено. И регулярно раздаются гневные высказывания в духе «почему в debian такой дырявый дефолтный umask».
Если пользователь хочет что-бы некоторые его файлы были доступны другим пользователям то он должен явно задать соответствующие права.

Вот пример:
Вебсервер с несколькими сайтами (php+mysql). Каждый сайт работает под своим пользователем (мы ведь не хотим что-бы взлом одного сайта скомпрометировал остальные). Один сайт взламывают, злоумышленник получает возможность выполнять произвольный код с правами пользователя под которым работает этот сайт. В файлах соседних сайтов он находит их логины и пароли к mysql (потому-что вебмастер забыл поправить права доступа к файлу), получает полный доступ к их базам данных, в случае некоторых популярных CMS это позволяет выполнить произвольный код от имени сайта. Изоляция летит к чертям.

MrClon ★★★★★ ()
Ответ на: комментарий от melkor217

Да. Например я скрываю пароли от админских учёток своих боевых серверов. Доктор, я параноик?

MrClon ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.