Note this, general issue exists in MySQL's Docker implementation as well-
https://stackoverflow.com/questions/35367935/mysql-in-docker-on-windows-world-writable-files-ignored

The base issue stems from Docker Desktop for Windows' decision about how to translate Windows file permissions to Linux permissions-

Permissions errors on data directories for shared volumes

When sharing files from Windows, Docker Desktop sets permissions on shared volumes to a default value of 0777 (read, write, execute permissions for user and for group).

The default permissions on shared volumes are not configurable. If you are working with applications that require permissions different from the shared volume defaults at container runtime, you need to either use non-host-mounted volumes or find a way to make the applications work with the default file permissions.

-https://docs.docker.com/desktop/windows/troubleshoot/#volumes

Here is MariaDB's current documentation on how to provide a custom configuration file-

Using a custom MariaDB configuration file

The startup configuration is specified in the file /etc/mysql/my.cnf, and that file in turn includes any files found in the /etc/mysql/conf.d directory that end with .cnf. Settings in files in this directory will augment and/or override settings in /etc/mysql/my.cnf. If you want to use a customized MariaDB configuration, you can create your alternative configuration file in a directory on the host machine and then mount that directory location as /etc/mysql/conf.d inside the mariadb container.

-https://hub.docker.com/_/mariadb

When following this procedure, users will get a warning like the below-

Warning: World-writable config file '/etc/mysql/conf.d/config-file.cnf' is ignored

Note this warning does not stop the container from launching. Instead, it results in the custom configuration file(s) not being kept and therefore not being used or loaded by the MariaDB instance. Especially when deploying via docker compose, it's easy for the warning to get lost in other log output, and this can often confuse users into thinking their custom configuration is applied and working when, in fact, it is not.

While there are many proposed work-arounds, the most reliable work-around I have found is to:

1. Mount the configuration file folder to a different target directory than MariaDB Docker image's documentation recommends
2. Mount that directory as a volume
3. Hijack the MariaDB Docker image's COMMAND to manually cp the mounted files into place and chmod such files to correct permissions, and to then call docker-entrypoint.sh mariadbd

Below is a snippet from a docker-compose.yml which handles this-

    volumes:

      - ./mariadb-config:/etc/mysql/config.d

    command: >

      bash -c "

      cp /etc/mysql/config.d/* /etc/mysql/conf.d/.

      && chmod 644 /etc/mysql/conf.d/*.cnf

      && /usr/local/bin/docker-entrypoint.sh mariadbd

      "

Given the permissions of the file(s) a user supplied to MariaDB's Docker image for the purposes of configuration should never need to be 777, it might make more sense to modify https://github.com/MariaDB/mariadb-docker/blob/master/Dockerfile.template or https://github.com/MariaDB/mariadb-docker/blob/master/docker-entrypoint.sh to detect and gracefully handle when 777 or other, non-viable permission masks are detected for such files.

The only problem this introduces is directly modifying the mounted file(s) may be problematic given Docker is maintaining an active link between the file outside the VM and the file inside the VM. It may make the most sense to just add a feature and update documentation to recommend Windows Docker users mount /etc/mysql/conf.windows.d/ instead and MariaDB's Docker implementation could just check if that directory exists, and if it does, just copy the contents of that directory to the target /etc/mysql/conf.d/ and ensure correct permissions post-copy.