Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bindmounts do not work due to permission issues #2

Open
needthisforctf opened this issue Jul 18, 2023 · 1 comment
Open

Bindmounts do not work due to permission issues #2

needthisforctf opened this issue Jul 18, 2023 · 1 comment

Comments

@needthisforctf
Copy link

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.

@needthisforctf
Copy link
Author

Any updates on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant