Переключення користувачів всередині образу Docker на некорневого користувача


80

Я намагаюся переключити користувача на користувача tomcat7, щоб налаштувати сертифікати SSH.

Коли я це роблю su tomcat7, нічого не відбувається.

whoami ще виконує коріння після виконання su tomcat7

Роблячи more /etc/passwd, я отримую такий результат, який чітко показує, що існує користувач tomcat7:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
messagebus:x:101:104::/var/run/dbus:/bin/false
colord:x:102:105:colord colour management daemon,,,:/var/lib/colord:/bin/false
saned:x:103:106::/home/saned:/bin/false
tomcat7:x:104:107::/usr/share/tomcat7:/bin/false

Я намагаюся обійти цю помилку в Гудзоні:

Command "git fetch -t git@________.co.za:_______/_____________.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: Host key verification failed.

Це мій файл Docker, він бере наявний файл війни гудзона та конфігурацію, який просмолюється та створює образ, хадсон працює нормально, він просто не може отримати доступ до git через неіснуючі сертифікати для користувача tomcat7.

FROM debian:wheezy

# install java on image
RUN apt-get update
RUN apt-get install -y openjdk-7-jdk tomcat7

# install hudson on image
RUN rm -rf /var/lib/tomcat7/webapps/*
ADD ./ROOT.tar.gz /var/lib/tomcat7/webapps/

# copy hudson config over to image
RUN mkdir /usr/share/tomcat7/.hudson
ADD ./dothudson.tar.gz /usr/share/tomcat7/
RUN chown -R tomcat7:tomcat7 /usr/share/tomcat7/

# add ssh certificates
RUN mkdir /root/.ssh
ADD ssh.tar.gz /root/

# install some dependencies
RUN apt-get update
RUN apt-get install --y maven
RUN apt-get install --y git
RUN apt-get install --y subversion

# background script
ADD run.sh /root/run.sh
RUN chmod +x /root/run.sh

# expose port 8080
EXPOSE 8080


CMD ["/root/run.sh"]

Я використовую останню версію Docker (версія Docker 1.0.0, збірка 63fe64c / 1.0.0), чи є це помилка в Docker, чи мені щось не вистачає у моєму Dockerfile?


4
Вам відома USERінструкція Dockerfile?
icecrime

1
Ні, для чого ви пропонуєте використовувати його?
Ян Володимир Мостерт

Чи можна було б генерувати сертифікати через Dockerfile за допомогою інструкції USER?
Ян Володимир Мостерт

3
Все, що ви виконуєте RUNпісля USERінструкції, виконується відповідно до uid, тому, хоча я не впевнений, що прекрасно розумію вашу проблему, схоже, це може бути те, що ви шукаєте.
icecrime

@icecrime не все, на жаль. COPYстворює файли як uid 0, що означає, що вони не можуть бути записані некореневим користувачем, і запуск RUN chown ...цих файлів не буде працювати, якщо поточний користувач також не є root. Таким чином, один із них закінчується перемиканням між root і іншим користувачем протягом Dockerfile.
davidA

Відповіді:


119

Ви не повинні використовувати suв файлі docker , однак ви повинні використовувати USERінструкції в файлі Docker.

На кожному етапі збірки Dockerfile створюється новий контейнер, тому будь-які зміни, внесені користувачем, не зберігатимуться на наступному етапі збірки.

Наприклад:

RUN whoami
RUN su test
RUN whoami

Це ніколи не означало б, що користувач буде таким, testяк новий контейнер з’являється на 2-му курсі. Результат буде кореневим для обох (якщо, звичайно, ви запустили USER заздалегідь).

Якщо ви все ж робите:

RUN whoami
USER test
RUN whoami

rootТоді ви мали б побачити test.

Крім того, ви можете запустити команду як інший користувач із sudo чимось подібним

sudo -u test whoami

Але, здається, краще скористатися офіційною підтримкою інструкції.


Мені цікаво, як переконатись, що попередньо запущені команди доступні користувачеві, встановленому в Dockerfile. У мене питання, де папки та дозволи, попередньо встановлені root, недоступні після переходу до іншого користувача з USERінструкцією.
Спенсер Вільямс

3
Можливо, вам знадобиться COPY --chown=myuser ...дорога.
x-yuri

39

Як інший підхід до іншої відповіді, замість того, щоб вказувати користувача при створенні зображення в Dockerfile, ви можете зробити це за допомогою командного рядка на конкретному контейнері як основу для кожної команди.

За допомогою docker execвикористовуйте, --userщоб вказати, який обліковий запис користувача використовуватиме інтерактивний термінал (контейнер повинен бути запущений, і користувач повинен існувати в контейнерній системі):

docker exec -it --user [username] [container] bash

Див. Https://docs.docker.com/engine/reference/commandline/exec/


6

Додайте цей рядок у файл docker

USER <your_user_name>

Використовуйте інструкцію докера USER


3

Ви також повинні мати можливість:

apt install sudo

sudo -i -u tomcat

Тоді ви повинні бути користувачем tomcat. Незрозуміло, який дистрибутив Linux ви використовуєте, але це працює, наприклад, з Ubuntu 18.04 LTS.


1

Якщо вам потрібно виконати привілейовані завдання, такі як зміна дозволів папок, ви можете виконувати ці завдання як кореневий користувач, а потім створити непривілейованого користувача та перейти до нього:

From <some-base-image:tag>

# Switch to root user
USER root # <--- Usually you won't be needed it - Depends on base image

# Run privileged command
RUN apt install <packages>
RUN apt <privileged command>

# Set user and group
ARG user=appuser
ARG group=appuser
ARG uid=1000
ARG gid=1000
RUN groupadd -g ${gid} ${group}
RUN useradd -u ${uid} -g ${group} -s /bin/sh -m ${user} # <--- the '-m' create a user home directory

# Switch to user
USER ${uid}:${gid}

# Run non-privileged command
RUN apt <non-privileged command>

-8

Не існує реального способу зробити це. Як результат, такі речі, як mysqld_safe, виходять з ладу, і ви не можете встановити mysql-сервер у контейнері док-станції Debian, не проскакуючи через 40 обручів, тому що .. ну ... це переривається, якщо це не root.

Ви можете використовувати USER, але ви не зможете apt-get install, якщо ви не root.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.