Improve security permissions in docker images

[EvgeniyPatlan]

According to docker best practises it is not recommended to run docker with root permissions. So it is better to use mysql user to run docker

[grooverdan]

recommend looking at #287 / #256. The root is used to change the ownership of VOLUME files but otherwise it changes quickly to mysql to continue. --user mysql will work, provided the ownership of the volume is right.

[EvgeniyPatlan]

hey @grooverdan I checked as you recommended https://github.com/MariaDB/mariadb-docker/blob/master/docker-entrypoint.sh#L500 But by default i see the following:

docker exec -it f19f758575da bash
root@f19f758575da:/#

So if I just run docker container using commands from docs I will get docker container running with root access which looks insecure. As for docker-compose from example:

FROM mariadb:10.4

# Create user and group
RUN groupadd -g 200000 dailyprophet
RUN useradd -u 200001 -g 200000 dailyprophet

# Set ownership of the mysql directory
RUN chown -R 200001:200000 /var/lib/mysql

WORKDIR /var/lib/mysql

There is easy fix that can do this:

FROM mariadb_my
USER root
# Create user and group
RUN groupadd -g 200000 dailyprophet
RUN useradd -u 200001 -g 200000 dailyprophet

# Set ownership of the mysql directory
RUN chown -R 200001:200000 /var/lib/mysql

WORKDIR /var/lib/mysql
USER mysql

So it will switch user to root to make privileged actions and then remove root permissions for future.

[grooverdan]

Sorry @EvgeniyPatlan, it can't work that way.

Simple version:

FROM ubuntu:22.04

# Create user and group
RUN groupadd -g 2000 dailyprophet
RUN useradd -u 2001 -g 2000 dailyprophet

# Set ownership of the mysql directory
RUN mkdir -p /test && chown -R dailyprophet:dailyprophet /test

VOLUME /test

My initial build with high uid numbers failed, there's a limit on what's allocated at runtime

$ buildah bud --tag uspecial 
STEP 1/5: FROM ubuntu:22.04
STEP 2/5: RUN groupadd -g 200000 dailyprophet
--> Using cache 85f15021666c8e0ff3f609474e8d87f6fbebd80c7e448a8e499760b94cfef087
--> 85f15021666c
STEP 3/5: RUN useradd -u 200001 -g 200000 dailyprophet
--> Using cache ea1700083b0a2f3fcdecc3d4bafca7bd58c2864cb640225efc20fbddd3cdc930
--> ea1700083b0a
STEP 4/5: RUN chown -R dailyprophet:dailyprophet /mnt
chown: changing ownership of '/mnt': Invalid argument
Error: building at STEP "RUN chown -R dailyprophet:dailyprophet /mnt": while running runtime: exit status 1

So (with lower uid numbers selected):

$ podman run --rm uspecial ls -la /test
total 12
drwxr-xr-x. 2 dailyprophet dailyprophet 4096 Feb  5 01:57 .

Yes we see the /test is writeable.

But create a volume and it isn't any more:

$ podman volume create us
us

$ podman run --rm -v us:/test  uspecial ls -la /test
total 12
drwxr-xr-x. 2 root root 4096 Feb  5 01:58 .
dr-xr-xr-x. 1 root root 4096 Feb  5 01:58 ..

$ podman run --rm -v us:/test --user dailyprophet   uspecial touch /test/make_a_file.txt
touch: cannot touch '/test/make_a_file.txt': Permission denied

Even adding USER to the file doesn't make volumes usable:

$ buildah bud --tag uspecial1
STEP 1/6: FROM ubuntu:22.04
STEP 2/6: RUN groupadd -g 2000 dailyprophet
--> Using cache 99fae287a0c4d96b94797fef861fdece45b3e2e4d2ed0867501e20437cc28981
--> 99fae287a0c4
STEP 3/6: RUN useradd -u 2001 -g 2000 dailyprophet
--> Using cache 7423855e82ce6031a92e0ff927995be878e42e74740dee859e03e8f53a39e5d1
--> 7423855e82ce
STEP 4/6: RUN mkdir -p /test && chown -R dailyprophet:dailyprophet /test
--> Using cache e4d89739755566b7cc404189315da5764a4ab92794e9fa8be2a641a312f9c7b2
--> e4d897397555
STEP 5/6: VOLUME /test
--> Using cache e819d848c895ea1003ad0b5312128d7a317679d1aeac4719c16c650bc0f57ae9
--> e819d848c895
STEP 6/6: USER dailyprophet
COMMIT uspecial1
--> d4636a8b3c69
Successfully tagged localhost/uspecial1:latest
d4636a8b3c6917aacd52d89bc2941690557ad16c22157cc6da1a4e5eb77b51fa

/tmp/d 
$ podman run --rm -v us:/test  uspecial1 touch /test/make_a_file.txt
touch: cannot touch '/test/make_a_file.txt': Permission denied

As MariaDB depends on having a persistent named volume being usable, this from of refactoring breaks user workflows.

Some security options are presented in #554.