Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uc2xN-008MjU-Mo for pgsql-general@arkaria.postgresql.org; Wed, 16 Jul 2025 14:18:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uc2xL-00Ad7S-FK for pgsql-general@arkaria.postgresql.org; Wed, 16 Jul 2025 14:18:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uc2xL-00Ad7K-32 for pgsql-general@lists.postgresql.org; Wed, 16 Jul 2025 14:17:59 +0000 Received: from mail-oo1-xc2c.google.com ([2607:f8b0:4864:20::c2c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uc2xJ-0084d8-0Z for pgsql-general@lists.postgresql.org; Wed, 16 Jul 2025 14:17:59 +0000 Received: by mail-oo1-xc2c.google.com with SMTP id 006d021491bc7-61593d5f92bso540257eaf.1 for ; Wed, 16 Jul 2025 07:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752675475; x=1753280275; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=5TohMQYQXKLh7GVFjgFHc21qgxFE2SH0rzm8vCGkHlw=; b=mqTG9Xb8dDU1uNai91hZzr4dp6ENN+vPhvMqBIOBhfOXYBrri6A+7UlI/pJKYxXLLA 2CLqi7eruQP6PMUbj9/RcOFduFPOIRyHhQdG6Qx8TccVxwfkPMp114B8ooIodtjFCyJ6 id1v9ZHte9oRpd1tIfC04wSjjQGC6lzul3p6HSLn3NuLb7QMdLPjUFcDHKpCOotilAhL 5i2HiFw5iDNa94bmDXhTI1vZD+P+QT317NkpZ3X3SUn4j4qh8zNeCGTIzOPY9dxHLOjR oAmRHdcK4NxUwzG7Id2zKKfUsD9LAO+tgA9cL9PHUHOcGEAy/m1bUuo16m7y1fWWxFg4 J/GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752675475; x=1753280275; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5TohMQYQXKLh7GVFjgFHc21qgxFE2SH0rzm8vCGkHlw=; b=ihXYut1FB8qAMHWFmZHCcA2MDq17Ucon37Vdi2a16VbbWSM+G0hbFgaaEjfh6p+aEY QNvn9pSvPuiRosugvAYT0Fm7cfHN8BfbaLv5nkYt2+Q37h3WWyecVoNjcE8Jx98CWDbE rrAgij+/xS1EXyjeBiTBGbPPn1vOhM+gADfct24UdLRKFZdeZ2rps+uAHcNLKazQxgC6 HmQzK3IDj5Y7NgstSc6bv0quVBdL3PABF0GMQW6csqpG7a40n6BRYKvcMT9C+DokLdk+ qU9fAXtwWcHGtiXBp+9OSuxxSs6CP5PRDuJvr5MsJg0hWQOCyxlWnUZuO8thhznmRb7Z nZ2Q== X-Gm-Message-State: AOJu0YxMexHBHQHk9OkJPoSmTv9BC6EuhvA4wMP8yIXMdK1+LOIMVvc0 XkFpZWTXJrbISMQU9m9+7DcXScLg46To4s1PhTEfA1pfkzzrYUn3eU/vIwF8RSw3yuxk7cwMJdE oDv1/YnTA8IuAbepb78hCB98Ik8JOwIE3yOhI X-Gm-Gg: ASbGncsyYVb1F5PJR5qmH8qjEkkapl3D2D6fuvPxmDxyiNndpnSDeug2xSdad/iF0GB RkdJ4xin6sCNs9/qSeWrI69Xc+baov5X6moHAWdeS+hbbE7gV7TPnGn8XJxghHHKk6aPoGCL3u8 s0VMhknMHGNKy9XnMr3tJZtpzX188lBuJFPd+ZJ2pkcOIui7JvsdCQfqV5tAv+Mk+xXnuoZGxHs BCCTlvp0VJYPYsytXSaB8rnRzT1iCGo8cUj0c1/Hw== X-Google-Smtp-Source: AGHT+IH/qd/Z4HCt11KvMhYCGLwP6SjkQgQozB/mYboCGbITA5CySw9vJ8YZ7781OlhVCleJzYUUrcsqon/pQ+zKfv4= X-Received: by 2002:a05:6820:308b:b0:613:bd07:54cc with SMTP id 006d021491bc7-6159ffd388cmr2478176eaf.0.1752675474579; Wed, 16 Jul 2025 07:17:54 -0700 (PDT) MIME-Version: 1.0 References: <13e3100fc7c7d14919c37943dcfd76b263cecce2.camel@cybertec.at> <609925.1752502040@sss.pgh.pa.us> In-Reply-To: From: Ron Johnson Date: Wed, 16 Jul 2025 10:17:43 -0400 X-Gm-Features: Ac12FXzIc0Z66eqOOYb1EqBgKbTWloNnuD27C7ybj7rM7-JWTwgDMefIWvPpm5w Message-ID: Subject: Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="00000000000011a6a6063a0c8fe0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000011a6a6063a0c8fe0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Quoting Tom's earlier email: "(But I too *would not use Postgres-over-NFS for any critical data*. Too many moving parts. It's tough enough to ensure crash safety with local storage.)" You're going through a lot of security effort to implement a Worst Practice= . On Wed, Jul 16, 2025 at 9:25=E2=80=AFAM Amol Inamdar w= rote: > Hi All, > > I would like to rephrase the question a little bit, below is how our setu= p > going to be > > 1. NFS mount point is for /nfs-mount/postgres (and permissions locked > 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 on= ly > the Posgres user can read/write to this directory) > > Considering the above scenario/setup, what is the danger of removing the > ownership check in miscinit.c checkDataDir() function ? > > > On Tue, Jul 15, 2025 at 5:06=E2=80=AFPM Amol Inamdar = wrote: > >> Thanks Tom and Laurenz for the explanation. >> Let me try out a few things and get back to you if needed. >> >> Thanks, >> Amol >> >> On Mon, Jul 14, 2025 at 7:37=E2=80=AFPM Tom Lane wro= te: >> >>> Laurenz Albe writes: >>> > It is not a good idea to have a mount point be the data directory. >>> >>> ^^^ This. ^^^ >>> >>> That is primarily for safety reasons: if for some reason the >>> filesystem gets dismounted, or hasn't come on-line yet during >>> a reboot, you do not want Postgres to be able to write on the >>> underlying mount-point directory. There is a sobering tale >>> in this old thread: >>> >>> >>> https://www.postgresql.org/message-id/flat/41BFAB7C.5040108%40joeconway= .com >>> >>> Now it didn't help any that they were using a start script that >>> would automatically run initdb if it didn't see a data directory >>> where expected. But even without that, you are in for a world of >>> hurt if the mount drops while the server is running and the server >>> has any ability to write on the underlying storage; it will think >>> whatever it was able to write is safely down on disk. To prevent >>> that, the server must not have write permissions on the mount >>> point, which dictates making a separate data directory (with >>> different ownership/permissions) just below the mount. >>> >>> Do not bypass that ownership/permissions check. It is there >>> for very good reasons. >>> >>> regards, tom lane >>> >> >> >> -- >> -regards >> Amol >> > > > -- > -regards > Amol > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --00000000000011a6a6063a0c8fe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Quoting Tom's earlier email:
"(But I too would not use Postgres-over-NFS for any critical data= .
Too many moving parts.=C2=A0 It's tough enough to ensure crash= safety
with local storage.)"

= You're going through=C2=A0a lot of security effort to implement a Worst= Practice.

On Wed, Jul 16,= 2025 at 9:25=E2=80=AFAM Amol Inamdar <amol.aai@gmail.com> wrote:
Hi All,

I would like to rephrase the question = a little bit, below is how our setup going to be=C2=A0
  1. NFS mount point is for = /nfs-mount/postgres (and permissions locked down so that Postgres cannot cr= eate directories in here)
  2. Postgres data directory is /nfs-mount/postgres/db

  3. Wit= h secured NFS + AT-TLS setup Postgres will be able to write to data directo= ry but not parent dir, however the file ownership information Postgres sees= from the=C2=A0stat()=C2=A0call will not match the Postgres user in the con= tainer (even though the AT-TLS strict access control will ensure only the P= osgres user can read/write to this directory)

Considering the above scenario/setup,=C2=A0what is th= e danger of removing the ownership check in=C2=A0miscinit.c=C2=A0checkDataD= ir()=C2=A0function ?=C2=A0


On Tue, Jul 15, 2025 at 5:06=E2=80=AFPM Amol Inamdar &= lt;amol.aai@gmail.c= om> wrote:
Thanks Tom and Laurenz for the explanation.=C2=A0
Le= t me try out a few things and get back to you if needed.

Thanks,
Amol

On Mon, Jul 14, 2025 at 7:37=E2=80=AFPM = Tom Lane <tgl@sss= .pgh.pa.us> wrote:
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> It is not a good idea to have a mount point be the data directory.

^^^ This. ^^^

That is primarily for safety reasons: if for some reason the
filesystem gets dismounted, or hasn't come on-line yet during
a reboot, you do not want Postgres to be able to write on the
underlying mount-point directory.=C2=A0 There is a sobering tale
in this old thread:

https://www.postgresql.or= g/message-id/flat/41BFAB7C.5040108%40joeconway.com

Now it didn't help any that they were using a start script that
would automatically run initdb if it didn't see a data directory
where expected.=C2=A0 But even without that, you are in for a world of
hurt if the mount drops while the server is running and the server
has any ability to write on the underlying storage; it will think
whatever it was able to write is safely down on disk.=C2=A0 To prevent
that, the server must not have write permissions on the mount
point, which dictates making a separate data directory (with
different ownership/permissions) just below the mount.

Do not bypass that ownership/permissions check.=C2=A0 It is there
for very good reasons.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 regards, tom lane


--
-regards
Amol


--
-regards
Amol


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--00000000000011a6a6063a0c8fe0--