How To Docker Copy to user root ~ - bash

I'm writing a Dockerfile to run ROS on my Windows rig and I can't seem to get this COPY command to copy to the container's user root or any sub directory there. I've tried a few things, including messing with the ownership. I know file is ugly but still learning. Not really sure what the issue is here.
This file sits next to a /repos dir which has a git repo within it which can be found here (the ros-noetic branch). This is also the location from which I build and run the container from.
Overall objective is to get roscore to run (which it has been), then exec in with another terminal and get rosrun ros_essentials_cpp (node name) to actually work
# ros-noetic with other stuff added
FROM osrf/ros:noetic-desktop-full
SHELL ["/bin/bash", "-c"]
RUN apt update
RUN apt install -y git
RUN apt-get update && apt-get -y install cmake protobuf-compiler
RUN bash
RUN . /opt/ros/noetic/setup.bash && mkdir -p ~/catkin_ws/src && cd ~/catkin_ws/ && chmod 777 src && catkin_make && . devel/setup.bash
RUN cd /
RUN mkdir /repos
COPY /repos ~/catkin_ws/src
RUN echo ". /opt/ros/noetic/setup.bash" >> ~/.bashrc

Expanding tilde to home directory is a shell feature, which apparently isn't supported in Dockerfile's COPY command. You're putting the files into a directory which is literally named ~, i.e. your container image probably contains something like this:
...
dr-xr-xr-x 13 root root 0 Jun 9 00:07 sys
drwxrwxrwt 7 root root 4096 Nov 13 2020 tmp
drwxr-xr-x 13 root root 4096 Nov 13 2020 usr
drwxr-xr-x 18 root root 4096 Nov 13 2020 var
drwxr-xr-x 2 root root 4096 Jun 9 00:07 ~ <--- !!!
Since root's home directory is always /root, you can use this:
COPY /repos /root/catkin_ws/src

You need to pay attention on the docker context.
When you build docker, you are adding the path to build your image.
If you are not on the / folder, your COPY /repos command won't work.
Try to change the docker context with that:
docker build /

Related

Dockerfile mkdir permission denied

I am trying to build the image with:
docker build -t db-demo .
But i get
RUN mkdir -p /usr/src/app:
#5 0.512 mkdir: cannot create directory '/usr/src/app': Permission denied
The Dockerfile
FROM mcr.microsoft.com/mssql/server
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
COPY . /usr/src/app
RUN chmod +x /usr/src/app/run-initialization.sh
ENV SA_PASSWORD bpassword
ENV ACCEPT_EULA Y
ENV MSSQL_PID Express
EXPOSE 1433
CMD /bin/bash ./entrypoint.sh
The OS is Windows.How to fix this?
If we start the mssql container with an interactive shell:
docker run -it --rm mcr.microsoft.com/mssql/server /bin/bash
and then look at the active user within the container:
mssql#ed73727870bb:/$ whoami
mssql
we see that the active user is mssql. Furthermore, if we look at the permissions for /usr/src inside the container:
mssql#ed73727870bb:/$ ls -lisa /usr | grep -i src
163853 4 drwxr-xr-x 2 root root 4096 Apr 15 2020 src
we see that only root has write-access to directory /usr/src.
Thus, if we want to create a directory /usr/src/app, so that user mssql can write to it, we will have to
create it as root and
grant the appropriate permissions to mssql.
This leads to the following Dockerfile:
FROM mcr.microsoft.com/mssql/server
# change active user to root
USER root
# create the app directory
RUN mkdir -p /usr/src/app
# set mssql as owner of the app directory
RUN chown mssql /usr/src/app
# change back to user mssql
USER mssql
WORKDIR /usr/src/app
# sanity check: try to write a file
RUN echo "Hello from user mssql" > hello.txt
if we build and run this Dockerfile:
docker build -t turing85/my-mssql -f Dockerfile .
docker run -it --rm turing85/my-mssql /bin/bash
We can now see that:
the active user is still mssql:
mssql#85e401ccc3f9:/usr/src/app$ whoami
mssql
a file /usr/src/app/hello.txt has been created, and user mssql has read-access:
mssql#85e401ccc3f9:/usr/src/app$ cat hello.txt
Hello from user mssql
user mssql has write-access to /usr/src/app:
mssql#85e401ccc3f9:/usr/src/app$ touch test.txt && ls -lisa
total 16
171538 4 drwxr-xr-x 1 mssql root 4096 Nov 6 20:13 .
171537 8 drwxr-xr-x 1 root root 4096 Nov 6 20:02 ..
171539 4 -rw-r--r-- 1 mssql root 17 Nov 6 20:02 hello.txt
171604 0 -rw-r--r-- 1 mssql root 0 Nov 6 20:13 test.txt
user mssql has no write-access to /usr/src:
mssql#85e401ccc3f9:/usr/src/app$ touch ../test2.txt
touch: cannot touch '../test2.txt': Permission denied
A comment on the Dockerfile in the post:
It seems that we try to copy an application into the mssql container. I assume this is done to start said application within the mssql container. While this is possible (with some configuration), I strongly advice against this approach. We could instead define two containers (one for the database, one for the application), e.g. through a docker-compose file.
WORKDIR creates the named directory if it doesn't exist. If your only permission problem is while trying to create the directory, you can remove the RUN mkdir line and let Docker create the directory for you.
FROM any-base-image
# Docker creates the directory if it does not exist
# You do not need to explicitly RUN mkdir
WORKDIR /usr/src/app
...
Looking further at this example, the RUN chmod ... line might also fail if the base image has a non-root user that can't access a root-owned directory. COPY will also copy the permissions from the host, so if the file is executable in the host environment you would not need to explicitly chmod +x it after it is COPYed in. That would let you delete all of the RUN lines; you'd be left with COPY and ENV instructions and runtime metadata, none of which should encounter permission problems.

Puppeteer sandbox : No usable sandbox

I installed Puppeteer to use it in the generation of pdf / minuatures, but I can not activate and configure Chrome Linux Sandbox. Always the same error message :
(node:46) UnhandledPromiseRejectionWarning: Error: Failed to launch chrome!
[1208/055442.253403:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
I followed the steps mentioned in the official documentation, but without success
# cd to the downloaded instance
cd <project-dir-path>/node_modules/puppeteer/.local-chromium/linux-<revision>/chrome-linux/
sudo chown root:root chrome_sandbox
sudo chmod 4755 chrome_sandbox
# copy sandbox executable to a shared location
sudo cp -p chrome_sandbox /usr/local/sbin/chrome-devel-sandbox
# export CHROME_DEVEL_SANDBOX env variable
export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox
Try with
sudo sysctl -w kernel.unprivileged_userns_clone=1
It will allows you, as unprivileged user, to access the sandbox of chromium.
This is temporary and active only until reboot.
You likely have the setuid bit wrong because of the cp command :
$ sudo touch orig
$ ls -l orig
-rw-r--r-- 1 root root 0 févr. 11 23:31 orig
$ sudo chmod 4755 orig
$ ls -l orig
-rwsr-xr-x 1 root root 0 févr. 11 23:31 orig
$ sudo cp orig new
$ ls -l new
-rwxr-xr-x 1 root root 0 févr. 11 23:31 new
The setuid bit (4th character) was changed from s to x after cp.

How can I run bash in a new container of a docker image?

I am able to run arbitrary shell commands in a container created from docker/whalesay image.
$ docker run docker/whalesay ls -l
total 56
-rw-r--r-- 1 root root 931 May 25 2015 ChangeLog
-rw-r--r-- 1 root root 385 May 25 2015 INSTALL
-rw-r--r-- 1 root root 1116 May 25 2015 LICENSE
-rw-r--r-- 1 root root 445 May 25 2015 MANIFEST
-rw-r--r-- 1 root root 1610 May 25 2015 README
-rw-r--r-- 1 root root 879 May 25 2015 Wrap.pm.diff
drwxr-xr-x 2 root root 4096 May 25 2015 cows
-rwxr-xr-x 1 root root 4129 May 25 2015 cowsay
-rw-r--r-- 1 root root 4690 May 25 2015 cowsay.1
-rw-r--r-- 1 root root 54 May 25 2015 install.pl
-rwxr-xr-x 1 root root 2046 May 25 2015 install.sh
-rw-r--r-- 1 root root 631 May 25 2015 pgp_public_key.txt
$ docker run docker/whalesay lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty
However, I am unable to run a shell in a container created from this image.
$ docker run docker/whalesay bash
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7ce600cc9904 docker/whalesay "bash" 5 seconds ago Exited (0) 3 seconds ago loving_mayer
Why did it not work? How can I make it work?
If you docker run without attaching a tty, and only call bash, then bash finds nothing to do, and it exits. That's because by default, a container is non-interactive, and a shell that runs in non-interactive mode expects a script to run. Absent that, it will exit.
To run a disposable new container, you can simply attach a tty and standard input:
docker run --rm -it --entrypoint bash <image-name-or-id>
Or to prevent the above container from being disposed, run it without --rm.
Or to enter a running container, use exec instead:
docker exec -it <container-name-or-id> bash
In comments you asked
Do you know what is the difference between this and docker run -it --entrypoint bash docker/whalesay?
In the two commands above, you are specifying bash as the CMD. In this command, you are specifying bash as the ENTRYPOINT.
Every container is run using a combination of ENTRYPOINT and CMD. If you (or the image) does not specify ENTRYPOINT, the default entrypoint is /bin/sh -c.
So in the earlier two commands, if you run bash as the CMD, and the default ENTRYPOINT is used, then the container will be run using
/bin/sh -c bash
If you specify --entrypoint bash, then instead it runs
bash <command>
Where <command> is the CMD specified in the image (if any is specified).

Unable to make file editable on Mac OS X

I'm trying to edit the httpd.conf file located in /private/etc/apache2, and I can't figure out how to get permission to write
I've done
$ cd /private/etc/apache2
$ sudo chown bdh httpd.conf
$ ls -lash
0 drwxr-xr-x 13 root wheel 442B Jun 7 00:11 .
0 drwxr-xr-x 93 root wheel 3.1K Jun 26 10:51 ..
0 drwxr-xr-x 13 root wheel 442B Jan 3 16:26 extra
24 -r--r--r-- 1 bdh wheel 24K Jun 7 00:11 httpd.conf
...etc...
$ vim httpd.conf
and it says "httpd.conf" [readonly] 677L, 24330C
tried cping to the desktop, but I cant get permission to edit it there either
I'm pretty new to using the terminal, is there some other command I can use?
It is normally unnecessary and undesirable to alter access permissions to edit a file. To edit a file that requires administrator (or other user) privileges without altering the access permissions, use:
sudo -e /private/etc/apache2
Sudo's -e option tells it you want to edit the given file.
This command copies the file and makes it writable by you, tells the editor specified with the SUDO_EDITOR, VISUAL or EDITOR environment variables (they're checked in that order) to edit the file, and when the editor exits, the file is copied back to the original without altering its access permissions.
See the sudo man page for details: x-man-page://8/sudo
The chmod command is what you're looking for I believe: http://en.wikipedia.org/wiki/Chmod
chmod 777 will let anyone read, write or execute for instance.
As richardhsu correctly added, 744 is RWX, R--,R-- and thats probably what you want.

Automake/autoconf configuration to install as SUID

Is there a way to configure a binary to be installed as "SUID" using automake/autoconf?
Is there any magick that can lead a make install to set the suid bit of a given binary target?
NOTE:
I am running a "fakerooted" make install inside a script to create a tar file.
I tried:
# Makefile.am
bin_PROGRAMS = my_bin
#...
install-exec-hook:
echo "#### Setting SUID for my_bin. ####"
ls -l $(DESTDIR)$(bindir)/my_bin
chmod 4755 $(DESTDIR)$(bindir)/my_bin
ls -l $(DESTDIR)$(bindir)/my_bin
echo "####-------------------------------####"
But with no success.
During make install I see:
#### Setting SUID for sudo_script. ####
-rwxr-xr-x 1 root root 8704 Mar 28 13:30 /install.pak/usr/bin/my_bin
-rwsr-xr-x 1 root root 8704 Mar 28 13:30 /install.pak/usr/bin/my_bin
####-------------------------------####
So one could think it is a problem with fakeroot, but if I move the chmod out of Makefile.am to my packaging script, it works. This is enough to convince me fakeroot is doing its job.
Thanks.
GAHH!!
Someone unconsciously put in my script, after $FAKEROOT make install:
$FAKEROOT chmod 755 $PAK_DIR/usr/bin/*
replacing all the permissions writen by make install.
Removing this line the install-exec-hook works as expected and the SUID bit is preserved...
(Were did I put my ax?...)

Resources