cat docker-compose.yaml
version: "3"
services:
pgtuned:
image: esgn/pgtuned:15
restart: always
environment:
POSTGRES_PASSWORD: changeme
volumes:
- ./tuned:/var/lib/postgresql/data
Running pgtuned like I described in this compose file above produces the following error: initdb: error: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted
The problem is that Dockerfile contains line USER postgres:postgres, which looks fine and dandy, until one starts doing bindmounts. The issue arises from the fact that docker daemon creates tuned directory itself, running as root, so it gets root:root ownership. But container runs as postgres:postgres. As a direct result of this, initdb scripts run with postgres user too and, thus, fail to fix permissions of their /var/lib/postgresql/data directory which is bindmounted to a directory owned by root.
I'd say since the purpose of this project is tuning for performance, not security, the user running the container shouldn't be changed in Dockerfile and it should run as root, since postgres process will eventually drop privileges itself and that's consistent with the way original postgres container operates. Otherwise users might be tempted to bindmount not /var/lib/postgresql/data, but /var/lib/postgresql, falsely assuming that bindmounting parent directory should produce the same effect while it doesn't for the reasons mentioned here.
For the same reasons, using named volume doesn't produce the issue, it only happens if you use docker with bindmounts, for which the host mountpoint haven't been created with proper (999:999) permissions beforehand.
Running pgtuned like I described in this compose file above produces the following error:
initdb: error: could not change permissions of directory "/var/lib/postgresql/data": Operation not permittedThe problem is that Dockerfile contains line
USER postgres:postgres, which looks fine and dandy, until one starts doing bindmounts. The issue arises from the fact that docker daemon createstuneddirectory itself, running as root, so it getsroot:rootownership. But container runs aspostgres:postgres. As a direct result of this, initdb scripts run withpostgresuser too and, thus, fail to fix permissions of their/var/lib/postgresql/datadirectory which is bindmounted to a directory owned by root.I'd say since the purpose of this project is tuning for performance, not security, the user running the container shouldn't be changed in Dockerfile and it should run as root, since postgres process will eventually drop privileges itself and that's consistent with the way original postgres container operates. Otherwise users might be tempted to bindmount not /var/lib/postgresql/data, but /var/lib/postgresql, falsely assuming that bindmounting parent directory should produce the same effect while it doesn't for the reasons mentioned here.
For the same reasons, using named volume doesn't produce the issue, it only happens if you use docker with bindmounts, for which the host mountpoint haven't been created with proper (999:999) permissions beforehand.