Chrome под Docker: CAP_SYS_ADMIN против привилегированных? [закрыто]

11

Закрыто. Этот вопрос не по теме . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он соответствовал теме отказа сервера.

Закрыто 10 месяцев назад .

Я запускаю chromedriver + chrome в Docker в моей тестовой среде.

Все работало нормально до последнего обновления CoreOS.

Вот версии, которые, кажется, работают:

VERSION=1185.5.0
VERSION_ID=1185.5.0
BUILD_ID=2016-12-07-0937

И это более новая версия, которая вызывает Chrome для Coredump:

VERSION=1235.4.0
VERSION_ID=1235.4.0
BUILD_ID=2017-01-04-0450

Глядя на изменения, кажется, что докер был обновлен с 1.11.x до 1.12.x, что прервало setns()вызов внутри контейнера. setns()используется Chrome для создания пространств имен.

Вот пример выходных данных:

jsosic-coreos-test-20161207 ~ # docker --version
Docker version 1.11.2, build bac3bae

Внутри одного контейнера на этой коробке:

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome
[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

Вот как новая версия сломала его:

jsosic-coreos-test-2017-01-04 ~ # docker --version
Docker version 1.12.3, build 34a2ead

[root@13ab34c36c82 /]# /opt/google/chrome/chrome
Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

Что я обнаружил, так это то, что если я запускаю контейнер с или --cap-add=SYS_ADMINили --privileged- Chrome работает как положено.

В чем разница между этими двумя переключателями? Какие возможности включены --privileged?

И, я могу позволить setns()внутри контейнера без ущерба для безопасности?

— Яков Сосич
источник

Спасибо за это. Я сделал проблему, используя множество ваших вещей: github.com/docker/for-linux/issues/496 Я думаю, что это должно быть исправлено

— Merc

Я опоздал почти на 2 года, но в заявке выше есть гораздо лучшее и безопасное решение, если вы все еще заинтересованы.

— Merc

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

— Merc

7

AFAICS, документация предлагает предоставить возможности, необходимые для контейнера, а не использовать --privilegedпереключатель. Запуск в привилегированном режиме, по- видимому, предоставляет контейнеру все возможности (в точности те, которые указаны в первом URL-адресе, при условии, что документы обновлены).

Короче говоря, я бы сказал, что это --cap-add=SYS_ADMINдает меньший набор возможностей для контейнера, по сравнению с --privilegedкоммутатором. В примерах, приведенных в документации Docker (первый URL), кажется, предпочтительнее просто добавить SYS_ADMINили NET_ADMINвозможность, где это необходимо.

— ivuk
источник

Спасибо, exec_linux.goпомогло. Я попытался клонировать репозиторий Docker, чтобы grep через него, но так как это заняло у меня пару часов, я просто забыл об этом :)

— Jakov Sosic

Просто для запуска Chrome, здесь есть гораздо лучшее решение: github.com/docker/for-linux/issues/496#issuecomment-441149510 Я думаю, что было бы очень полезно обновить ответ, чтобы люди делали то, что я объясняю в тот самый комментарий. Пожалуйста, дайте мне знать, если вы согласны.

— Merc

1

Одно из отличий состоит в том, что --privileged монтирует / dev и / sys как RW, где SYS_ADMIN монтирует их как RO. Это означает, что привилегированный контейнер имеет полный доступ к устройствам в системе. SYS_ADMIN не дает вам этого.

— mel1990
источник