Копирование файлов с разрешениями на выполнение в Docker Image - PullRequest
Новая
       17

Копирование файлов с разрешениями на выполнение в Docker Image

0 голосов
/ 12 июня 2019

Похоже на основную проблему, но пока не смог найти никаких ответов.

При использовании ADD / COPY в Dockerfile и запуске образа в linux разрешение по умолчанию для файла, скопированного в образ, составляет 644. Похоже, что владельцем этого файла является root '

Однако при запуске образа пользователь без полномочий root запускает контейнер, и любой файл, скопированный таким образом с разрешением 644, не может выполнить этот скопированный / добавленный файл, и если файл выполняется в ENTRYPOINT, он не запускается с ошибкой отказа в разрешении.

Я прочитал в одном из постов, что COPY / ADD после Docker 1.17.0+ разрешает chown, но в моем случае я не знаю, кто будет пользователем без полномочий root, поэтому я не могу установить разрешение в качестве этого пользователя.

Я также видел другую работу по добавлению / копированию файлов в другое место и использованию RUN для копирования их из временного местоположения в фактическую папку, как показано ниже. Но этот подход не работает, так как конечное изображение не имеет файлов в / otp / scm 

#Installing Bitbucket and setting variables  
WORKDIR /tmp
ADD atlassian-bitbucket-${BITBUCKET_VERSION}.tar.gz .
COPY bbconfigupdater.sh .

#Copying Entrypoint script which will get executed when container starts 
WORKDIR /tmp 
COPY entrypoint.sh .

RUN ls -lrth /tmp

WORKDIR /opt/scm 
RUN pwd && cp /tmp/bbconfigupdater.sh /opt/scm \
 && cp /tmp/entrypoint.sh /opt/scm \
 && cp -r /tmp/atlassian-bitbucket-${BITBUCKET_VERSION} /opt/scm \
 && chgrp -R 0 /opt/ \
 && chmod -R 755 /opt/ \
 && chgrp -R 0 /scm/bitbucket \
 && chmod -R 755 /scm/bitbucket \
 && ls -lrth /opt/scm && ls -lrth /scmdata

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

1 Ответ

0 голосов
/ 12 июня 2019

Разрешение по умолчанию для файла - это то, что относится к разрешению файла в контексте вашей сборки, откуда вы копируете файл. Если вы контролируете источник, то лучше исправить разрешения, чтобы избежать операции копирования при записи. В противном случае, если вы не можете гарантировать, что при сборке системы для файла будет установлен бит выполнения, a chmod после операции копирования исправит разрешение. Э.Г. 

RUN chmod +x entrypoint.sh

Вам не нужно знать, кто будет управлять контейнером. Пользователь внутри контейнера обычно настраивается создателем образа (используя USER) и не зависит от пользователя, запускающего контейнер с хоста докера. Когда пользователь запускает контейнер, он отправляет запрос в API докера, который не отслеживает идентификатор вызывающего пользователя.

Единственный раз, когда я видел, что пользователь хоста имеет значение, это если у вас есть том хоста и вы хотите избежать проблем с разрешениями. Если это ваш сценарий, я часто запускаю точку входа как root, запускаю скрипт с именем fix-perms , чтобы выровнять uid контейнера с uid тома хоста, а затем запускаю gosu, чтобы переключиться с root обратно на пользователя контейнера. .

...