Description
This is related to #641 (which is closed).
The mysql image is supposed to support using a custom uid/gid (see Running as an arbitrary user).
In practice, this doesn't work with docker-compose, because the /var/lib/mysql directory is owned by the mysql image user with id 999. /var/lib/mysql is defined as a volume in the image, so it makes sense to define a named volume to use it with docker-compose. But even when permissions to the volume are fixed, within a container they will always be the permissions set by the image, and the custom user defined with user: in the docker-compose file will not have access.
To work around this issue, I tried to run the container as root (without using user:) and define a custom entrypoint in docker-compose with entrypoint:, which was fixing permissions in the container and executing the image's entrypoint with the custom user. That didn't work, because I needed to use sudo and apparently this is not part of buster-slim.
I then tried another workaround: using --datadir in a custom entrypoint, and a named volume pointing to a directory different from /var/lib/mysql. That works, but a new volume with a random name is created every time the application starts because of the volume defined in the image for /var/lib/mysql. So I have to create an "unused" named volume for /var/lib/mysql to work around that... That's rather ugly.
A possible fix for these issues would be to use environment variables instead of user:, change the Dockerfile to install sudo, and change the mysql image entrypoint to fix permissions to /var/lib/mysql if necessary and use something like sudo -u "#$MYSQL_USER_UID" -g "#$MYSQL_USER_GID" to continue.
To explain the context, I looked into using a custom user because I needed to share the socket file with the host to allow a backup with it (the backup software we use requires a socket file). But I didn't want user 999 on the host to have access to it.