You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 createstuned
directory itself, running as root, so it getsroot:root
ownership. But container runs aspostgres:postgres
. As a direct result of this, initdb scripts run withpostgres
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.
The text was updated successfully, but these errors were encountered: