Thread: postgres and initdb not working inside docker
postgres and initdb not working inside docker.
chmod 755 always for a mounted volume inside docker.
=============
From: Roffild <roffild@hotmail.com>
Subject: fix chmod inside docker
diff --git a/src/backend/utils/init/miscinit.c
b/src/backend/utils/init/miscinit.c
index 30f0f19dd5..adf3218cf9 100644
--- a/src/backend/utils/init/miscinit.c
+++ b/src/backend/utils/init/miscinit.c
@@ -373,7 +373,7 @@ checkDataDir(void)
*/
#if !defined(WIN32) && !defined(__CYGWIN__)
if (stat_buf.st_mode & PG_MODE_MASK_GROUP)
- ereport(FATAL,
+ ereport(WARNING,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("data directory \"%s\" has invalid permissions",
DataDir),
Roffild <roffild@hotmail.com> writes:
> postgres and initdb not working inside docker.
> chmod 755 always for a mounted volume inside docker.
This patch will never be accepted. You don't need it if you take the
standard advice[1] that the Postgres data directory should not itself
be a mount point. Instead, make a subdirectory in the mounted volume,
and that can have the ownership and permissions that the server expects.
regards, tom lane
[1] https://www.postgresql.org/message-id/12168.1312921709%40sss.pgh.pa.us
Only in an ideal world are all standards observed... Docker has different standards inside. $ ls -l /home/neo/ drwxr-xr-x 2 pgsql pgsql 8192 May 27 10:37 data drwxr-sr-x 2 pgsql pgsql 4096 May 24 09:35 data2 /home/pgsql/data - mounted volume. Therefore, the permissions have changed to drwxr-xr-x $ mkdir /home/pgsql/data/pgtest $ ls -l /home/pgsql/data drwxr-xr-x 2 pgsql pgsql 0 May 27 11:08 pgtest $ chmod 700 /home/pgsql/data/pgtest $ ls -l /home/pgsql/data drwxr-xr-x 2 pgsql pgsql 0 May 27 11:08 pgtest Oops... If it's a regular "data2" folder and there is no "read_only: true" flag for the container: $ mkdir /home/pgsql/data2/pgtest $ chmod 700 /home/pgsql/data2/pgtest $ ls -l /home/pgsql/data2 drwx------ 2 pgsql pgsql 4096 May 27 11:19 pgtest > Roffild writes: >> postgres and initdb not working inside docker. >> chmod 755 always for a mounted volume inside docker. > > This patch will never be accepted. You don't need it if you take the > standard advice[1] that the Postgres data directory should not itself > be a mount point. Instead, make a subdirectory in the mounted volume, > and that can have the ownership and permissions that the server expects. > > regards, tom lane > > [1] https://www.postgresql.org/message-id/12168.1312921709%40sss.pgh.pa.us
Add --disable-check-permissions to ./configure After applying the patch, run "autoheader -f ; autoconf" This patch fixes an issue inside Docker and will not affect other builds.
Attachment
> On 28 May 2022, at 14:59, Roffild <roffild@hotmail.com> wrote: > This patch fixes an issue inside Docker and will not affect other builds. Looks like you generated the patch backwards, it's removing the lines you propose to add. -- Daniel Gustafsson https://vmware.com/
Fix > Looks like you generated the patch backwards, it's removing the lines you > propose to add.
Attachment
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 28 May 2022, at 14:59, Roffild <roffild@hotmail.com> wrote:
>> This patch fixes an issue inside Docker and will not affect other builds.
> Looks like you generated the patch backwards, it's removing the lines you
> propose to add.
Lacks documentation, too. But it doesn't matter, because we are not
going to accept such a "feature". The OP has offered no justification
why this is necessary (and no, he's not the first who's ever used
Postgres inside Docker). Introducing a security hole that goes
against twenty-five years of deliberate project policy is going to
require a heck of a lot better-reasoned argument than "there's an
issue inside Docker".
regards, tom lane
> On 28 May 2022, at 17:49, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <daniel@yesql.se> writes: >>> On 28 May 2022, at 14:59, Roffild <roffild@hotmail.com> wrote: >>> This patch fixes an issue inside Docker and will not affect other builds. > >> Looks like you generated the patch backwards, it's removing the lines you >> propose to add. > > Lacks documentation, too. But it doesn't matter, because we are not > going to accept such a "feature". The OP has offered no justification > why this is necessary (and no, he's not the first who's ever used > Postgres inside Docker). Introducing a security hole that goes > against twenty-five years of deliberate project policy is going to > require a heck of a lot better-reasoned argument than "there's an > issue inside Docker". FWIW, I 100% agree. -- Daniel Gustafsson https://vmware.com/
Docker is now the DevOps standard. It's easier to build an image for Docker and run the site with one command. But the volume mount has a limitation with chmod 755. I don't want to write the database directly to the container. The container is isolated from everything. Therefore, checking the file permissions inside the container is meaningless. And writing to the container is also a "security hole". The world has changed! And the old standards don't work... 28.05.2022 18:49, Tom Lane: > Lacks documentation, too. But it doesn't matter, because we are not > going to accept such a "feature". The OP has offered no justification > why this is necessary (and no, he's not the first who's ever used > Postgres inside Docker). Introducing a security hole that goes > against twenty-five years of deliberate project policy is going to > require a heck of a lot better-reasoned argument than "there's an > issue inside Docker".
On Sat, May 28, 2022 at 9:35 AM Roffild <roffild@hotmail.com> wrote:
Docker is now the DevOps standard. It's easier to build an image for
Docker and run the site with one command.
But the volume mount has a limitation with chmod 755. I don't want to
write the database directly to the container.
The container is isolated from everything. Therefore, checking the file
permissions inside the container is meaningless. And writing to the
container is also a "security hole".
The world has changed! And the old standards don't work...
Given the general lack of clamoring for this kind of change I'd be more inclined to believe that your specific attempt at doing this is problematic rather than there being a pervasive incompatibility between Docker and PostgreSQL. There is a host environment, a container environment, multiple ways to expose host resources to the container, and the command line and/or docker file configuration itself. None of which you've shared. So I think that skepticism about your claims is quite understandable.
My suspicion is you aren't leveraging named volumes to separate the container and storage and that doing so will give you the desired separation and control of the directory permissions.
Based upon my reading of:
and limited personal experience using Docker, I'm inclined to believe it can be made to work even if you cannot do it exactly the way you are trying right now. Absent a use case for why one way is preferable to another having the bar set at "it works if you do it like this" seems reasonable.
David J.
On Sat, May 28, 2022, 18:35 Roffild <roffild@hotmail.com> wrote:
> But the volume mount has a limitation with chmod 755. I don't want to
> write the database directly to the container.
Using a $PGDATA subdirectory in a mounted Volume allows you to run with 0700
and also retain this limitation you mention. I don't believe this limitation is a limitation
of Docker - AFAIK Docker uses the permissions from the Host Directory for the Mount.
In my experience we have been using (since 2014?) a subdirectory of the mounted Volume
and run a statement similar to this on startup of your container, before starting postgres/initdb or the like
install -o postgres -g postgres -d -m 0700 "${PGDATA}"
> The world has changed! And the old standards don't work...install -o postgres -g postgres -d -m 0700 "${PGDATA}"
It does work!
Kind regards,
Feike Steenbergen