Allow arbitrary --user values (mostly)

[tianon]

One special case is that initdbrequires the current user to exist in /etc/passwd, but running PostgreSQL itself does not require that.

As discussed over in #93 (comment).

See also docker-library/rabbitmq#60, docker-library/cassandra#48, docker-library/mongo#81, redis/docker-library-redis#48, docker-library/mysql#161, MariaDB/mariadb-docker#59, docker-library/percona#21, and TryGhost/docker-library-ghost#54.

Closes#46
Closes#116
Closes#206
Closes#251
Ref #28

[tianon]

$ docker run -it --rm --user 1000:1000 postgresinitdb: could not look up effective user ID 1000: user does not exist
$ docker run -it --rm --user www-data postgresThe files belonging to this database system will be owned by user "www-data".This user must also own the server process....
$ docker run -it --rm --user "$(id -u):$(id -g)" -v /etc/passwd:/etc/passwd:ro postgresThe files belonging to this database system will be owned by user "tianon".This user must also own the server process....
$ dir="$(mktemp -d)"
$ docker run -it --rm -v "$dir":/var/lib/postgresql/data postgres... (let initialization finish, then stop the server)
$ sudo chown -R 1000:1000 "$dir"
$ docker run -it --rm -v "$dir":/var/lib/postgresql/data --user 1000:1000 postgresLOG: database system was shut down at 2017-01-19 23:06:31 UTCLOG: MultiXact member wraparound protections are now enabledLOG: database system is ready to accept connectionsLOG: autovacuum launcher started

[tianon]

The following comment from docker-library/mysql#161 (comment) also applies here:

I think the main difference is that the initdb.d scripts will no longer be run as root; not sure if that will break too many users.

[yosifkit]

With regards to my comment of it breaking people that are taking advantage of being root while in initdb.d scripts, I would point out that the change was pushed to mysql on May 17, 2016 and to mariadb and percona on May 18. 2016 and there has yet to be an issue reported about it.

[yosifkit]

We'll probably want to add some docs about the limitations observed here.

[tianon]

docker-library/docs#802 👍

[srstsavage]

FWIW this did cause an issue for us, as a .pgpass file provided in a volume mounted to /root/.pgpass suddenly stopped working. It took a while to figure out why with inconsistent behavior between various postgres:9.6 images cached on different workstations/servers. Easy fix once we figured out what was going on, but it wasn't immediately obvious.

The How to extend this image section in the docs stll doesn't explicitly say that *.sh scripts will be run by the postgres user by default, that might help.

[tianon]

Excellent idea, thanks @shane-axiom ❤️

I've filed a PR at docker-library/docs#848 👍

[tianon]

This PR isn't (and really can't) be the cause of PostgreSQL not working on Windows -- it doesn't change anything about how postgres itself runs. The bit you quoted refers to how /docker-entrypoint-initdb.dscripts are run -- previously those ran as root, now they run as the same user PostgreSQL does (which makes way more sense anyhow).

If you want to bypass our behavior entirely, it should be trivial to do so via --entrypoint postgres (which would be the only way to start the postgres daemon itself as root with the current image script, although I'm not sure whether PostgreSQL itself will allow that or whether it balks at running as root).

[yosifkit]

@willemavjc, try this comment: #558 (comment).

tldr: it is not possible on Docker for Windows for Postgres to use a shared folder to the host

[willemavjc]

@willemavjc, try this comment: #558 (comment).

tldr: it is not possible on Docker for Windows for Postgres to use a shared folder to the host

Thanks for sharing some links. Yes, that's the conclusion I ended up with. And yes, the only way with Docker for Windows to make "persistent" data is through a volume which is well documented on Docker documentation; in fact that was the first thing I tried when discovering docker/postgres.

BUT... As a matter of fact, no one no longer can call this "persistent" data, "semi-persistent" data at the most if one really want to believe his data will last for ...some time.

Because the Docker volume is on Windows limited to an inner directory within Moby, then the data will not survive any issue with Docker itself requiring a reset, for whatever the reason may be: unrecoverable crashes, environment refresh, etc. Said differently, the data is not onto the host fs, living on its own.

Trying to fake the volume within Moby with a symlink made me realize the things which dysfunction: Moby writes on shared volumes as root, not a unprivileged user. When using Alpine of Postgres, one can write to Windows fs because I believe it passes all the way down root privileges. On the other hand, when logged as postgres, the story ends fast because it simply is not privileged; --privileged=true did nothing by the way.

So the solution would either manage somehow postgres to write data as root or Docker to remap unprivilege writes operations as root for shared folders.

Opened for any discussion on this point of view.