Closed MiltiadisKoutsokeras closed 1 year ago
Bitnami containers are designed to operate as non-root by default. Consequently, any files or directories used by the application should be owned by the root group, as the random user (1001 by default) is a member of this root group. To ensure proper permissions, you'll need to adjust the ownership of your local directory accordingly.
For more comprehensive information about non-root containers and their significance for security, you can explore the following resources:
These references provide valuable insights into the best practices and considerations when working with non-root containers in Bitnami applications.
Using a non-root/rootless Docker setup to launch the docker compose
command with the attached compose.yaml
reproduces the error. It seems there was effort made to make the containers run fron non-root host users, but the problem exists.
By the way, I am not mounting any volumes from local folders, I will try this also.
By adding volumes to compose YAML:
services:
database:
image: docker.io/bitnami/mariadb:11.0
ports:
- "127.0.0.1:3306:3306/tcp"
environment:
MARIADB_MASTER_PORT_NUMBER: 3306
MARIADB_ROOT_PASSWORD: mariadb_root_pass
MARIADB_DATABASE: wordpress
MARIADB_USER: wordpress_user
MARIADB_PASSWORD: wordpress_pass
volumes:
- ./bitnami_mariadb:/bitnami/mariadb
wordpress:
image: docker.io/bitnami/wordpress:6
ports:
- "127.0.0.1:8080:8080/tcp"
- "127.0.0.1:8443:8443/tcp"
depends_on:
- database
environment:
WORDPRESS_USERNAME: test
WORDPRESS_PASSWORD: test_pass
WORDPRESS_DATABASE_HOST: database
WORDPRESS_DATABASE_PORT_NUMBER: 3306
WORDPRESS_DATABASE_NAME: wordpress
WORDPRESS_DATABASE_USER: wordpress_user
WORDPRESS_DATABASE_PASSWORD: wordpress_pass
volumes:
- ./bitnami_wordpress:/bitnami/wordpress
The database cannot start at all:
50295-database-1 | mariadb 08:44:19.32
50295-database-1 | mariadb 08:44:19.32 Welcome to the Bitnami mariadb container
50295-database-1 | mariadb 08:44:19.32 Subscribe to project updates by watching https://github.com/bitnami/containers
50295-database-1 | mariadb 08:44:19.32 Submit issues and feature requests at https://github.com/bitnami/containers/issues
50295-database-1 | mariadb 08:44:19.33
50295-database-1 | mariadb 08:44:19.33 INFO ==> ** Starting MariaDB setup **
50295-database-1 | mariadb 08:44:19.35 INFO ==> Validating settings in MYSQL_*/MARIADB_* env vars
50295-database-1 | mariadb 08:44:19.35 INFO ==> Initializing mariadb database
50295-database-1 | mkdir: cannot create directory '/bitnami/mariadb/data': Permission denied
50295-database-1 exited with code 1
50295-wordpress-1 | wordpress 08:44:19.76
50295-wordpress-1 | wordpress 08:44:19.76 Welcome to the Bitnami wordpress container
50295-wordpress-1 | wordpress 08:44:19.76 Subscribe to project updates by watching https://github.com/bitnami/containers
50295-wordpress-1 | wordpress 08:44:19.76 Submit issues and feature requests at https://github.com/bitnami/containers/issues
50295-wordpress-1 | wordpress 08:44:19.76
50295-wordpress-1 | wordpress 08:44:19.77 INFO ==> ** Starting WordPress setup **
50295-wordpress-1 | wordpress 08:44:19.79 INFO ==> Generating sample certificates
50295-wordpress-1 | Generating RSA private key, 4096 bit long modulus (2 primes)
50295-wordpress-1 | ................................................................................................................................................................................................................................................................................................................................................................................................++++
50295-wordpress-1 | ...............................++++
50295-wordpress-1 | e is 65537 (0x010001)
50295-wordpress-1 | Signature ok
50295-wordpress-1 | subject=CN = example.com
50295-wordpress-1 | Getting Private key
50295-wordpress-1 | realpath: /bitnami/apache/conf: No such file or directory
50295-wordpress-1 | wordpress 08:44:21.24 INFO ==> Configuring Apache ServerTokens directive
50295-wordpress-1 | wordpress 08:44:21.27 INFO ==> Configuring PHP options
50295-wordpress-1 | wordpress 08:44:21.27 INFO ==> Setting PHP expose_php option
50295-wordpress-1 | wordpress 08:44:21.29 INFO ==> Setting PHP output_buffering option
50295-wordpress-1 | wordpress 08:44:21.61 INFO ==> Validating settings in MYSQL_CLIENT_* env vars
50295-wordpress-1 | wordpress 08:44:21.66 WARN ==> Hostname database could not be resolved, this could lead to connection issues
50295-wordpress-1 | wordpress 08:44:22.42 INFO ==> Ensuring WordPress directories exist
50295-wordpress-1 | wordpress 08:44:22.42 INFO ==> Trying to connect to the database server
50295-wordpress-1 | wordpress 08:45:22.61 ERROR ==> Could not connect to the database
50295-wordpress-1 exited with code 1
The MariadDB image is marked as non-root in the link you shared.
Using Podman to launch the containers showcases a similar error:
podman network create github-issue-50295
podman run --detach --network github-issue-50295 --name database \
-p 3306:3306 \
--env MARIADB_MASTER_PORT_NUMBER=3306 \
--env MARIADB_ROOT_PASSWORD=mariadb_root_pass \
--env MARIADB_DATABASE=wp_langaware_db \
--env MARIADB_USER=wp_langaware \
--env MARIADB_PASSWORD=wp_langaware_pass \
docker.io/bitnami/mariadb:11.0
podman run --network github-issue-50295 --name wordpress \
-p 8080:8080 -p 8443:8443 \
--env WORDPRESS_USERNAME=langaware \
--env WORDPRESS_PASSWORD=langaware_pass \
--env WORDPRESS_DATABASE_HOST=database \
--env WORDPRESS_DATABASE_PORT_NUMBER=3306 \
--env WORDPRESS_DATABASE_NAME=wp_langaware_db \
--env WORDPRESS_DATABASE_USER=wp_langaware \
--env WORDPRESS_DATABASE_PASSWORD=wp_langaware_pass \
docker.io/bitnami/wordpress:6
Output:
wordpress 11:39:57.57
wordpress 11:39:57.57 Welcome to the Bitnami wordpress container
wordpress 11:39:57.57 Subscribe to project updates by watching https://github.com/bitnami/containers
wordpress 11:39:57.57 Submit issues and feature requests at https://github.com/bitnami/containers/issues
wordpress 11:39:57.58
wordpress 11:39:57.58 INFO ==> ** Starting WordPress setup **
wordpress 11:39:57.61 INFO ==> Generating sample certificates
Generating RSA private key, 4096 bit long modulus (2 primes)
..........................................................................................................................++++
...++++
e is 65537 (0x010001)
Signature ok
subject=CN = example.com
Getting Private key
realpath: /bitnami/apache/conf: No such file or directory
wordpress 11:39:58.13 INFO ==> Configuring Apache ServerTokens directive
wordpress 11:39:58.17 INFO ==> Configuring PHP options
wordpress 11:39:58.17 INFO ==> Setting PHP expose_php option
wordpress 11:39:58.19 INFO ==> Setting PHP output_buffering option
wordpress 11:39:58.53 INFO ==> Validating settings in MYSQL_CLIENT_* env vars
wordpress 11:39:59.86 INFO ==> Ensuring WordPress directories exist
wordpress 11:39:59.86 INFO ==> Trying to connect to the database server
wordpress 11:39:59.94 INFO ==> Configuring WordPress with settings provided via environment variables
wordpress 11:40:00.93 INFO ==> Installing WordPress
wordpress 11:40:10.80 INFO ==> Persisting WordPress installation
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/extensions/blocks/cookie-consent': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/src': Directory not empty
Adding volumes (--volume mariadb_data:/bitnami/mariadb
and --volume wordpress_data:/bitnami/wordpress
respectively) does not change the behavior.
Update: the compose.yaml
attached in this issue can be launched with root host user, if no host directory is mounted to the containers. If you add something like this:
volumes:
- ./bitnami_wordpress:/bitnami/wordpress
to the wordpress
container the process again fails due to permission error:
wordpress 08:08:27.06
wordpress 08:08:27.06 Welcome to the Bitnami wordpress container
wordpress 08:08:27.06 Subscribe to project updates by watching https://github.com/bitnami/containers
wordpress 08:08:27.06 Submit issues and feature requests at https://github.com/bitnami/containers/issues
wordpress 08:08:27.06
wordpress 08:08:27.06 INFO ==> ** Starting WordPress setup **
wordpress 08:08:27.07 INFO ==> Generating sample certificates
Generating RSA private key, 4096 bit long modulus (2 primes)
......................................................................................................................................................................................................++++
...++++
e is 65537 (0x010001)
Signature ok
subject=CN = example.com
Getting Private key
realpath: /bitnami/apache/conf: No such file or directory
wordpress 08:08:27.55 INFO ==> Configuring Apache ServerTokens directive
wordpress 08:08:27.56 INFO ==> Configuring PHP options
wordpress 08:08:27.56 INFO ==> Setting PHP expose_php option
wordpress 08:08:27.57 INFO ==> Setting PHP output_buffering option
wordpress 08:08:27.58 INFO ==> Validating settings in MYSQL_CLIENT_* env vars
wordpress 08:08:27.68 INFO ==> Ensuring WordPress directories exist
wordpress 08:08:27.68 INFO ==> Trying to connect to the database server
wordpress 08:08:32.69 INFO ==> Configuring WordPress with settings provided via environment variables
wordpress 08:08:33.19 INFO ==> Installing WordPress
wordpress 08:08:34.26 INFO ==> Persisting WordPress installation
cp: cannot create regular file '/bitnami/wordpress/wp-config.php': Permission denied
The ./bitnami_wordpress
folder in the host is owned by root, so the container's non-root user cannot write into it.
There is something wrong with file ownership and permission in this container. Launching the container with Bash instead of the default entrypoint:
docker run --rm --tty --interactive --entrypoint /bin/bash bitnami/wordpress:6
showcases the following:
$ id
uid=1001 gid=0(root) groups=0(root)
$ id daemon
uid=1(daemon) gid=1(daemon) groups=1(daemon)
$ ls -la /bitnami/wordpress
total 8
drwxrwxr-x 2 daemon root 4096 Sep 27 01:24 .
drwxr-xr-x 3 root root 4096 Sep 27 01:24 ..
So the wordpress files belong to daemon(1):root(0) although the run user is uid=1001 gid=0(root)
. Another strange behavior is that files in /opt/bitnami/wordpress/wp-content
cannot be deleted with a single rm -rf
command but require multiple tries:
$ rm -rf /opt/bitnami/wordpress/wp-content
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/w3-total-cache/vendor/aws/aws-sdk-php/src/Neptune': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/all-in-one-seo-pack/vendor_prefixed/monolog/monolog/src/Monolog/Handler/Slack': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/amp/vendor/ampproject/amp-toolbox/src/Dom': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/simple-tags/vendor/sabre/vobject/lib/Component': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/wp-mail-smtp/vendor_prefixed/monolog/monolog/src/Monolog/Handler/Slack': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/modules/seo-tools': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/extensions/blocks/cookie-consent': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/src': Directory not empty
$ rm -rf /opt/bitnami/wordpress/wp-content
$ echo $?
0
$ ls -la /opt/bitnami/wordpress/wp-content
ls: cannot access '/opt/bitnami/wordpress/wp-content': No such file or directory
Seeing this completelly strange behavior, I am suspecting that this whole issue is deeper inside the Docker implementation of the filesystem driver. I cannot analyze it further, I will have to find a mitigation strategy.
This seems to be a unique use case that might be challenging to replicate on our end, as it appears closely tied to your particular scenario. We are not able to manually reproduce this issue nor it is being detected in our automated tests.
As you rightly say, the user running the container is uid=1001, gid=0 root and the folders where this user needs to write are owned by the root group; this combination is enough for the application to work out of the box. Any modification in this sense can make the container to fail.
In case someone also has the same problem, here is a quick workaround to mitigate the problems:
775
and ownership belonging to the user that launches docker compose
/bitnami/wordpress
.+++ b/bitnami/wordpress/6/debian-11/prebuildfs/opt/bitnami/scripts/libpersistence.sh
@@ -99,7 +99,15 @@ restore_persisted_app() {
# We use 'realpath --no-symlinks' to ensure that the case of '.' is covered and the directory is removed
file_to_restore_origin="$(realpath --no-symlinks "${install_dir}/${file_to_restore_relative}")"
file_to_restore_destination="$(realpath --no-symlinks "${persist_dir}/${file_to_restore_relative}")"
- rm -rf "$file_to_restore_origin"
+ while true
+ do
+ # Fix issue https://github.com/bitnami/containers/issues/50295
+ if rm -rf "${file_to_restore_origin}"
+ then
+ info "Successfully deleted ${file_to_restore_origin}"
+ break
+ fi
+ done
ln -sfn "$file_to_restore_destination" "$file_to_restore_origin"
done
}
For example:
wordpress:
image: docker.io/bitnami/wordpress:6
ports:
- "127.0.0.1:8080:8080/tcp"
- "127.0.0.1:8443:8443/tcp"
depends_on:
- database
environment:
WORDPRESS_USERNAME: langaware
WORDPRESS_PASSWORD: langaware_pass
WORDPRESS_DATABASE_HOST: database
WORDPRESS_DATABASE_PORT_NUMBER: 3306
WORDPRESS_DATABASE_NAME: wp_langaware_db
WORDPRESS_DATABASE_USER: wp_langaware
WORDPRESS_DATABASE_PASSWORD: wp_langaware_pass
volumes:
# Fix issue https://github.com/bitnami/containers/issues/50295
- ./src/backend/opt/bitnami/scripts/libpersistence.sh:/opt/bitnami/scripts/libpersistence.sh:ro
# Wordpress site content, permissions of ./bitnami_wordpress should be rwxrwxr-x
- ./bitnami_wordpress:/bitnami/wordpress:rw
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.
Name and Version
bitnami/wordpress:6
What architecture are you using?
amd64
What steps will reproduce the bug?
Create the following
compose.yaml