MIME-Version: 1.0
References: <CAGOe9RiRUK9K8gUbsMfg8nWDsM2Fd9py-2oe4VG1Uaggu8fQGA@mail.gmail.com>
 <13e3100fc7c7d14919c37943dcfd76b263cecce2.camel@cybertec.at>
 <609925.1752502040@sss.pgh.pa.us> <CAGOe9RirtoXtMJhejo4_V+Si83+c4gfM_E-DH9WqaEBJ9SnfiA@mail.gmail.com>
 <CAGOe9RiBSEZo3c8akePA+11HmV1JHx0Lsk57-fGfM0DEf4ekXg@mail.gmail.com> <62b420e1c9500c68c1bc135810d4cf9f3289fb8c.camel@cybertec.at>
In-Reply-To: <62b420e1c9500c68c1bc135810d4cf9f3289fb8c.camel@cybertec.at>
From: Amol Inamdar <amol.aai@gmail.com>
Date: Thu, 17 Jul 2025 10:22:37 +0530
Message-ID: <CAGOe9RjzoPnc5ZsTMHjDLn2BAX++G2VznP2zLcWkO3Ba1sSJTA@mail.gmail.com>
Subject: Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with
 Secure z/OS NFS (AT-TLS)
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000fb9c05063a18c7e9"
Archived-At: <https://www.postgresql.org/message-id/CAGOe9RjzoPnc5ZsTMHjDLn2BAX%2B%2BG2VznP2zLcWkO3Ba1sSJTA%40mail.gmail.com>
Precedence: bulk

--000000000000fb9c05063a18c7e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@Laurenz Albe <laurenz.albe@cybertec.at>
If you pre-create the data directory with the appropriate permissions,
what keeps you from giving ownership to the correct user too?

Our NFS server is not a regular linux based server,
it's on zOS (Mainframes) with AT-TLS security enabled,
hence it doesn't allow changing of ownership.

Basically, we have tried everything we could
to change the directory ownership to match with the postgres user
and that as of now looks impossible, unless we make changes in the
environment.

To summarize*, we are not able to change the ownership of the data
directory *
*due to the Mainframe NFS server limitations when enabled with AT-TLS
security *
*Hence we wanted to check if bypassing this check is ok if it could be
assured *
*that only the postgres user can write here (NFS-AT-TLS ensures that). *

I wouldn't get into details of explaining why changing ownership is not
possible,
as that would take this discussion to another context, hence avoiding.

Thanks in advance

On Wed, Jul 16, 2025 at 9:18=E2=80=AFPM Laurenz Albe <laurenz.albe@cybertec=
.at>
wrote:

> On Wed, 2025-07-16 at 18:54 +0530, Amol Inamdar wrote:
> > I would like to rephrase the question a little bit, below is how our
> setup going to be
> >    1. NFS mount point is for /nfs-mount/postgres (and permissions locke=
d
> down so
> >       that Postgres cannot create directories in here)
> >    2. Postgres data directory is /nfs-mount/postgres/db
> >    3. With secured NFS + AT-TLS setup Postgres will be able to write to
> data directory
> >       but not parent dir, however the file ownership information
> Postgres sees from the
> >       stat() call will not match the Postgres user in the container
> (even though the
> >       AT-TLS strict access control will ensure only the Posgres user ca=
n
> read/write to
> >       this directory)
> > Considering the above scenario/setup, what is the danger of removing th=
e
> ownership check
> > in miscinit.c checkDataDir() function ?
>
> The danger is that somebody else than the PostgreSQL user has permissions
> on
> the data directory.  You will argue that that somebody is root, and root
> has
> these permissions anyway.
>
> But there is another reason why PostgreSQL insists that the PostgreSQL us=
er
> owns the data directory: at startup, the postmaster checks if the data
> directory belongs to the current user and fails if not.  This is a
> protection
> against starting the postmaster with the wrong user.
>
> There are certainly ways to do it differently, but I'd argue that they
> would
> be more complicated, and the current simple solution is robust.
>
> If you pre-create the data directory with the appropriate permissions,
> what keeps you from giving ownership to the correct user too?
>
> Yours,
> Laurenz Albe
>


--=20
-regards
Amol

--000000000000fb9c05063a18c7e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><a class=3D"gmail_plusreply" id=3D"plusReplyChip-1" href=
=3D"mailto:laurenz.albe@cybertec.at" tabindex=3D"-1">@Laurenz Albe</a>=C2=
=A0<br><div>If you pre-create the data directory with the appropriate permi=
ssions,<br>what keeps you from giving ownership to the correct user too?<di=
v><br></div><div>Our NFS server is not a regular linux based server,=C2=A0<=
/div><div>it&#39;s on zOS (Mainframes) with AT-TLS security enabled,=C2=A0<=
/div><div>hence it doesn&#39;t allow changing of ownership.=C2=A0</div><div=
><br></div><div>Basically, we have tried everything we could=C2=A0</div><di=
v>to change the directory ownership to match with the postgres user</div><d=
iv>and that as of now looks impossible, unless we make changes in the envir=
onment.</div><div><br></div><div>To summarize<b>, we are not able to change=
 the ownership of the data directory=C2=A0</b></div><div><b>due to the Main=
frame NFS server limitations when enabled with AT-TLS security=C2=A0</b></d=
iv><div><b>Hence we wanted to check if bypassing this check is ok if it cou=
ld be assured=C2=A0</b></div><div><b>that only the postgres user can write =
here (NFS-AT-TLS ensures that).=C2=A0</b></div><div><br></div><div>I wouldn=
&#39;t get into details of=C2=A0explaining why changing ownership is not po=
ssible,=C2=A0</div><div>as that would take this discussion to another conte=
xt, hence avoiding.</div><div><br></div><div>Thanks in advance=C2=A0</div><=
/div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D=
"ltr" class=3D"gmail_attr">On Wed, Jul 16, 2025 at 9:18=E2=80=AFPM Laurenz =
Albe &lt;<a href=3D"mailto:laurenz.albe@cybertec.at">laurenz.albe@cybertec.=
at</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">On Wed, 2025-07-16 at 18:54 +0530, Amol Inamdar wrote:<br>
&gt; I would like to rephrase the question a little bit, below is how our s=
etup going to be=C2=A0<br>
&gt; =C2=A0=C2=A0=C2=A01. NFS mount point is for /nfs-mount/postgres (and p=
ermissions locked down so<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0that Postgres cannot create directories in h=
ere)<br>
&gt; =C2=A0=C2=A0=C2=A02. Postgres data directory is /nfs-mount/postgres/db=
<br>
&gt; =C2=A0=C2=A0=C2=A03. With secured NFS + AT-TLS setup Postgres will be =
able to write to data directory<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0but not parent dir, however the file ownersh=
ip information Postgres sees from the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0stat()=C2=A0call will not match the Postgres=
 user in the container (even though the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0AT-TLS strict access control will ensure onl=
y the Posgres user can read/write to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0this directory)<br>
&gt; Considering the above scenario/setup,=C2=A0what is the danger of remov=
ing the ownership check<br>
&gt; in=C2=A0miscinit.c=C2=A0checkDataDir()=C2=A0function ?=C2=A0<br>
<br>
The danger is that somebody else than the PostgreSQL user has permissions o=
n<br>
the data directory.=C2=A0 You will argue that that somebody is root, and ro=
ot has<br>
these permissions anyway.<br>
<br>
But there is another reason why PostgreSQL insists that the PostgreSQL user=
<br>
owns the data directory: at startup, the postmaster checks if the data<br>
directory belongs to the current user and fails if not.=C2=A0 This is a pro=
tection<br>
against starting the postmaster with the wrong user.<br>
<br>
There are certainly ways to do it differently, but I&#39;d argue that they =
would<br>
be more complicated, and the current simple solution is robust.<br>
<br>
If you pre-create the data directory with the appropriate permissions,<br>
what keeps you from giving ownership to the correct user too?<br>
<br>
Yours,<br>
Laurenz Albe<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature">-regards<br>Amol</div>

--000000000000fb9c05063a18c7e9--