Docker container creates user and chowns datadir causing havoc

[idontusenumbers]

The docker container creates a new 'mysql' user and entrypoint.sh chown's the entire data directory to that user.

This causes nothing but trouble when mounting the mysql data directory as a volume using docker-compose. From the host's perspective, all files are owned by uid 999. This is either going to conflict with an existing user or be an unassigned uid.

To make things worse, this behavior is poorly documented and hidden inside docker files and shell scripts.

Be cause of how embedded these commands are, it's difficult to override these actions so it doesn't happen or to 'recover' from them on the host.

What's the goal of these user-related steps?

[wglambert]

You can run as an arbitrary user to pick a specific UID/GID https://github.com/docker-library/docs/tree/master/mysql#running-as-an-arbitrary-user

The mysql process in the container has to run as a user, and that user also owns the data directory
The host UID 999 will be exactly the same as the container's UID 999 for interacting with the mounted volume, the name of the user isn't relevant.

[idontusenumbers]

I tried using the user directive on the docker compose but files were still chowned to mysql.

The dockerfile unconditionally creates a new user and entrypoint unconditionally (as far as I can tell; there's a strange condition around it that I don't understand) runs as mysql.

From what I can gather, everything inside a docker container starts running as root (the entrypoint.sh for example), but if something spins off as another user from there, the change on the command line or compose file wouldn't affect it.

if I run two two mysql containers, one as user1 and one as user2, both will chown the data to user 999, and there's no way to differentiate between the two 999s.

[wglambert]

USER in a Dockerfile still requires something like RUN groupadd -r user && useradd --no-log-init -r -g user user
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user

I'm not sure what the expectation is with the user that mysql runs as, that mysql user isn't created on your host, it's just mysql in the container and whoever 999 is on your host. The entrypoint starts a temporary server for initilization, then steps down from root. The entrypoint only does this if there's no database present, otherwise it won't modify an existing database

But again the name itself doesn't matter for host->container volume interaction, just the UID. You'll need an empty volume so it can be reinitialized with a new UID

$ mkdir test

$ sudo chmod 777 test

$ docker run -d --rm --name mysql --user 4007:4007 -v "$PWD"/test:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root mysql 
73972a7e18ef4bd978c6dd9f960fd74805e32e33326c8979367ae95a1fdff702

$ ls -l test/
total 178196
-rw-r----- 1 4007 4007       56 Feb 24 11:12  auto.cnf
-rw-r----- 1 4007 4007  3084516 Feb 24 11:13  binlog.000001
-rw-r----- 1 4007 4007      155 Feb 24 11:13  binlog.000002
-rw-r----- 1 4007 4007       32 Feb 24 11:13  binlog.index
-rw------- 1 4007 4007     1676 Feb 24 11:12  ca-key.pem
-rw-r--r-- 1 4007 4007     1112 Feb 24 11:12  ca.pem
[. . .]

[idontusenumbers]

I was able to chown to the user running on my host. Later, the mysql container modified the user (or deleted the file then recreated it; like transaction log files).

The problem here is precisely this:

whoever 999 is on your host

[wglambert]

chown'ing the files doesn't change the UID that the container's mysqld process is running as, any new files will be made as the running UID and you may encounter permission issues by doing so

I'm going to close as this isn't an issue with the image, for further help you should try asking over at the Docker Community Forums, Docker Community Slack, or Stack Overflow.

[idontusenumbers]

I'm not sure I'm making the problem clear.

Given the current implementation, these are the problems:

• All mysql containers use the same, fixed UID
• That UID can collide with the host system
• The explicit user parameter passed to docker is effectively ignored

[yosifkit]

All mysql containers use the same, fixed UID

That is by design. The image is deterministic; users already have trouble with file system access and permissions.

---

That UID can collide with the host system

There is no issue here. Any user id we pick will conflict with someone's host system. Which is one reason we have the ability to run as any arbitrary user.

If you don't want your local user id to have access to your database files, then pass a different user and group (like --user 888:888) to the docker run as you would for any container that you want to run as a specific user. Or if you do want to own those files as your non-root user, then something like this:

$ mkdir mysql-data
$ docker run -u "$(id -u):$(id -g)" -e MYSQL_ROOT_PASSWORD=12345 -v "$PWD/mysql-data/":/var/lib/mysql/ mysql:8

You could also look to user namespaces, but that complicates file system access even more.

---

The explicit user parameter passed to docker is effectively ignored

How exactly are you passing this and was the volume empty before starting (docker-compose file contents, commands you ran, etc). We'd like to be able to reproduce the error.

@wglambert's example shows how to run as any user id you desire. But you are then responsible for providing a volume that has permissions appropriate for that user to access (since the entrypoint wouldn't be able to chown it for you anymore).

---

The entrypoint script will only switch (by re-execing itself) to the mysql user (via gosu) if it is running as root, otherwise it doesn't have a way to switch to another user.

[idontusenumbers]

That is by design. The image is deterministic; users already have trouble with file system access and permissions.

I'm not sure I follow. I had permission problems with what exists now; I ran into even more permissions problems because of the opaque workarounds in place.

---

There is no issue here. Any user id we pick will conflict with someone's host system.

I'm having a hard time understanding how the conflict you and I both described isn't an issue. I find it really confusing that the user id is specified 'from within' the container instead of 'from outside' the container.

This workaround precludes "running as the current user" (without an additional layer of scripting to replace the user override with the current user)

---

We'd like to be able to reproduce the error.

I was finally able to get my user-override working. I followed the example at https://docs.docker.com/compose/compose-file/#domainname-hostname-ipc-mac_address-privileged-read_only-shm_size-stdin_open-tty-user-working_dir which passes a user by name. restarting the container did not pick up the change. After many attempts at troubleshooting I finally realized I had to use a different command (doh!). After using this other command I saw this error:

ERROR: for mysqltest_db_1  Cannot start service db: unable to find user idontusenumbers: no matching entries in passwd file

It's printed in the host's passwd file clear as day. I don't know why this was failing.

I then tried a user id as a number but that didn't work either.

The key was a number as a string:

user: "1000"

This finally worked and my files are now owned by the correct user.

Now the problem is that this compose file is totally not portable and will only work on my machine, which I think is a problem.

[wglambert]

It's printed in the host's passwd file clear as day. I don't know why this was failing.

Because the container doesn't have the same files as the host unless you mount it in

$ docker exec mysql cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/bin/false
mysql:x:999:999::/home/mysql:

As I said a few times before the username isn't relevant in this context, It's the UID that matters, UID 999 can be mysql in the container and idontusenumbers on the host, they both own the data.
I demonstrated how simple it is to set the UID #641 (comment)

confusing that the user id is specified 'from within' the container instead of 'from outside' the container.

Because the mysqld process has to be run for the container to exist, and that process requires a UID running it. Thus a non-root UID is selected
Once the container is running there can't be a UID change to the PID 1 process, how would it be "externally" set?

Why not just make a user on the host with UID 1337 and set the container to run as UID 1337, then you have a designated user to access the database files if you don't want your normal user to do so. If you want your container's UID 1337 to have a name then mount your /etc/passwd read-only or make that specific username in the container so it has a name in /etc/passwd

[yosifkit]

This workaround precludes "running as the current user" (without an additional layer of scripting to replace the user override with the current user)

That is how docker containers work; they run as the user they specify and you can override that (warning that many image examples will fail to run as an arbitrary user). That fact that a docker-compose file doesn't have an easy way (https://jtreminio.com/blog/running-docker-containers-as-current-host-user/) to do so is not a problem with the image.