Menu
I'm using Docker (1.3.1) to build RPMs inside a container:
docker run -v /home/matt/build:/build build-rpm /build/build-pkg.sh This works fine (my user is in the docker group, so I don't need to sudo) and drops a completed .rpm file in the current directory. The problem is that the file is created as owned by root.
How can I arrange it so that the file is created owned by the same user as I run docker with?
816
The best way to prevent privilege-escalation attacks from within a container is to configure your container's applications to run as unprivileged users. For containers whose processes must run as the root user within the container, you can re-map this user to a less-privileged user on the Docker host.
What is “running as root”? Running a container as root means that the software packaged in a container is set to start as the root, or system administrator, user. This user is special in Linux systems, because it has all permissions needed to administer a system.
The most notable difference between the two options is that --mount is more verbose and explicit, whereas -v is more of a shorthand for --mount . It combines all the options you pass to --mount into one field. On the surface, both commands create a PostgreSQL container and set a volume to persist data.
Multiple containers can run with the same volume when they need access to shared data. Docker creates a local volume by default.
If you start a container with a volume that does not yet exist, Docker creates the volume for you. The following example mounts the volume myvol2 into /app/ in the container. The -v and --mount examples below produce the same result.
Volume drivers let you store volumes on remote hosts or cloud providers, to encrypt the contents of volumes, or to add other functionality. New volumes can have their content pre-populated by a container. Volumes on Docker Desktop have much higher performance than bind mounts from Mac and Windows hosts.
volume ownership is not under control of docker-compose, so this discussion should take place under moby project repo. Docker volume, when first used by a container, get it's initial content and permission inherited from the container. Which mean you can configure your image like this :
Originally, the -v or --volume flag was used for standalone containers and the --mount flag was used for swarm services. However, starting with Docker 17.06, you can also use --mount with standalone containers. In general, --mount is more explicit and verbose.
You could try to create (in the Dockerfile of a custom image) a user and set it as the one used by the container
RUN adduser --system --group --shell /bin/sh auser \ && mkdir /home/auser/bin USER auser Then check if a docker run -v /home/matt/build:/build build-rpm mounts the shared folder in /build as auser.
Another option mentioned in issue 2259:
If you
chownthe volume (on the host side) before bind-mounting it, it will work.
In that case, you could do:
mkdir /tmp/www chown 101:101 /tmp/www docker run -v /tmp/www:/var/www ubuntu stat -c "%U %G" /var/www (Assuming that
101:101is theUID:GIDof thewww-datauser in your container.)
124
Docker runs as root and has no idea what your user is inside its virtual environment (even if you're in the sudoers group). But you can create a non-root user while building your docker image that can be called whatever you like.
# create a non-root user named tester, # give them the password "tester" put them in the sudo group RUN useradd -d /home/tester -m -s /bin/bash tester && echo "tester:tester" | chpasswd && adduser tester sudo # start working in the "tester" home directory WORKDIR /home/tester COPY ./src # Make the files owned by tester RUN chown -R tester:tester /home/tester # Switch to your new user in the docker image USER tester If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
