Can't connect from other applications by default

[ndarilek]

Seeing the following in docker-entrypoint.sh:

{ echo; echo "host all \"$POSTGRES_USER\" 0.0.0.0/0 $authMethod"; } >> "$PGDATA"/pg_hba.conf

Today I tried to launch a Redmine container I'd built with this image in mind, and have working on another host, and it failed due to a missing pg_hba.conf line. When I compared the working line with the newly-generated one, I discovered "all" was replaced with $POSTGRES_USER.

Why is this? I guess I can spin up a new database per app, but that seems a bit wasteful. Also, if I understand correctly, I'm now expected to connect my app authenticating against $POSTGRES_USER, which is a superuser. So, unless I'm missing something, you've switched the default mode of operation from "everyone can connect, with authorization handled on the user level" to "only $POSTGRES_USER can connect by default, and $POSTGRES_USER is superuser." That strikes me as absolutely backwards, in the sense that I should be handing out credentials piecemeal rather than connecting to the superuser by default.

I know I can change this with my own scripts, but unless I'm missing something, this default seems absolutely broken.

[groob]

I'd like some clarification on this as well.

[yosifkit]

The reason for the change was #31 (pr #36). I made a note over there.

[ToBeReplaced]

I am upset over how this was handled.

I had a long running 9.3 container, dumped the database, then tried to restore the database on a new host running a fresh container. I run with icc=False and was relying on postgresql not applying its own security. I was not able to proceed with 9.4, and the offending changes appear to have been back applied to 9.3, so when I pull a new 9.3 image it doesn't match my previous one.

Thus, I can no longer use previously known working code. This should never happen.

[java-artisan]

Why not provide an option to let people chose ?

[yosifkit]

This has been reverted in the most recent change. We were trying to fix "security", but went more than people were expecting.

[workmaster2n]

Can I ask why this change was reverted? I understand that the change broke formerly working code, but I was a big fan of the change. I'm used to a postgres setup (non-docker) that requires some configuration in order to access and was really surprised when I found that trust line. I understand that I can configure a password or ship in my own pg_hba.conf, but I also ran a couple test containers with the -P flag thinking they were in no real danger. Also, the tutorials I was following ran the container with the -d flag, so my logs weren't shown on the console.

I do appreciate that with the trust enabled, someone getting into docker and postgres for the first time would have fewer technical hurdles to address (either modifying pg_hba.conf or providing a password), but I'm wondering if features like that should be included in an image flagged demo or insecure or some other indication of maybe-not-perfect-for-production.

I understand that if I don't expose the container to the outside world, the trust doesn't really matter, but in my configuration I was planning on having outside access so I could use command line tools to administer my database. At that point would it make sense to run postgres in a non-docker environment? Probably. But I figured if I was dockerizing part of the app, why not do the whole thing?

Is there a discussion group or something where we can keep all the talk on issues like this centralized? I'd love to just stay abreast of what different parties were saying and help out where I can. I noticed this was also discussed in issue #31 and pr #36 and I might be missing some other comments.

[ndarilek]

I'm using docker exec to administer the Postgres instance. That seems somewhat more secure than allowing remote access to non-consuming containers. Am I missing something security-wise that would make this a bad idea? I get that if someone compromises my server then they have access to my database, but I think that's more or less always been true unless you put forth extra effort to block it which, while nice to do anyway, isn't really the default in non-Docker installs either. Since the config is generated, maybe an environment variable passed to the container can toggle this behavior? Then you can start with a more secure server and tweak the configuration as needed once it lands on the filesystem.

[yosifkit]

It was only partially reverted, if you provide a POSTGRES_PASSWORD the authentication from the pg_hba.conf will still be md5 but will not be restrictive on user, so that you can add more users and not be restricted by the pg_hba.conf.