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 1uc28C-008CTy-JZ for pgsql-general@arkaria.postgresql.org; Wed, 16 Jul 2025 13:25:08 +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 1uc28A-00AIHv-MG for pgsql-general@arkaria.postgresql.org; Wed, 16 Jul 2025 13:25:07 +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 1uc28A-00AIHn-9i for pgsql-general@lists.postgresql.org; Wed, 16 Jul 2025 13:25:06 +0000 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uc288-0084Ey-1G for pgsql-general@lists.postgresql.org; Wed, 16 Jul 2025 13:25:06 +0000 Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-aec46b50f33so45971966b.3 for ; Wed, 16 Jul 2025 06:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752672303; x=1753277103; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KgvxxJ2I6S8ax+5fVcCi7QCMyUPc7XrigYbNE2Ilowk=; b=feZovBr/EfHCY29KrXSuLZKQo0E8gmCqj0Nu7BgFr9YGN5Cet32g7afvSWKCaexTmS HThlLgpkGxJsQ8rUTNdxrse0WhN8FkA5BBee1i8wmmp8OYJoFAA08FnYSZUrSgp5b+4A 5F5I1JkW/QxCotQByCT1K+5XkXdPgW6TIHMMrEOSQ2EZoKE1m5d8BmzK70C+N2F0Qekm cK+bzwfMs54QllFOBwuFq4AnY0mPx5C3Ch8KXaRiHMzp1fv6N9PVg5VWc8lVf3FcXdZs YLZGHPPLPNqbDny+CsGmif3eg5ySSgImg3XUBfbRl1J56m22QWUWvb0zbAqQDJdTYz3M gfhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752672303; x=1753277103; h=cc: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=KgvxxJ2I6S8ax+5fVcCi7QCMyUPc7XrigYbNE2Ilowk=; b=eAeMkesLcr89LYevilXAhDYQwFduLB0UxF2LhkDgkvQ7VJIBXpNnyv5udx7UY+IDE8 JToX5JMB8YqotybD29EgbyE42/sWemwYyXpFgr9ctUz2SdGwZG+EfsFNa/QHUxmzah6S Zmm46RDo6Q+lHiiosLnoQ4IoxAOWaThs0BmTZDmkKEdCFlaire/+094NSCvZ2sao3Ei6 ak0HjkeRKpIcrrPHb3QNBHAknf0vnZU7E+f2FG51lGr5vdWn3QRkrjSHe39X9yP7xRgI HlD/4wjocl70aiySl+Aw8pA8CfV90IlHDsShkTtfZaaDMYkeAWKFTnNxV9unxW+pAmkY rOkw== X-Forwarded-Encrypted: i=1; AJvYcCUobA+kwkEKVL//qX9GraRSghJopbZg8V4bIwJFd/k0IwWsasf7s6nZwRD/5edT96twTHJ7kMNtKnn8TZEP@lists.postgresql.org X-Gm-Message-State: AOJu0YxIZ/Zij+G6/17uWSnGbl9yaCfX3VEXzKh01RxwFiIhKrK+WxvU MREJ4EJKEDsSOtmWXzlxRJTmksiRDr+WmOk8rAuKKMvGmU4prQEWVXe7HtT6SSuUhHsZvhyOO7C 2v5Gu+FUYoePM9BidN/T/VfC06AMJtrBGh9XaHRc= X-Gm-Gg: ASbGncsFqbIHzndafun3nEm+hzXF6qNgKC9vNj57BTmL2NNCfAaPcH2nvoik2VHL2iU 9vRpNtCgCNzFUKpPMIQIQRySCtGiISGTXny/T0MYT6RwryaangB043i526aRzpFdexrau9e7EBO g48459ApexcNlmN6qdzIArmOISfn1ga7zdVn+3abckkqXu4lJ8j5+tJxolXaSayDTL0g5BMXtd1 u8AnI9WhnZKA1dELAfhNOs2AhGBYTO/GVokcxAc X-Google-Smtp-Source: AGHT+IHYVU+CWR7+jIjheAS//88SQ0N7QzpBjPdwVHgRVUhKiA3O849bRY7NFmh7ZOylfJw26FfajvEwHSMeEnuvgqU= X-Received: by 2002:a17:906:6a1c:b0:ae0:3391:f068 with SMTP id a640c23a62f3a-ae9cddd03c5mr264597166b.19.1752672302568; Wed, 16 Jul 2025 06:25:02 -0700 (PDT) MIME-Version: 1.0 References: <13e3100fc7c7d14919c37943dcfd76b263cecce2.camel@cybertec.at> <609925.1752502040@sss.pgh.pa.us> In-Reply-To: From: Amol Inamdar Date: Wed, 16 Jul 2025 18:54:50 +0530 X-Gm-Features: Ac12FXwDqJWfIPojyf19vB3Z6-_qJPmVY8nvne2D5Imd4uhAkWceRnrHtKBK44o Message-ID: Subject: Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) To: Tom Lane Cc: Laurenz Albe , pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000009ee1063a0bd285" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000009ee1063a0bd285 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, 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 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 t= he container (even though the AT-TLS strict access control will ensure only 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 w= rote: > 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 wrot= e: > >> 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 > --=20 -regards Amol --000000000000009ee1063a0bd285 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I would like to rephrase the qu= estion 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 tha= t 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 wr= ite to data directory but not parent dir, however the file ownership inform= ation Postgres sees from the=C2=A0stat()=C2=A0call will not match the Postg= res user in the container (even though the AT-TLS strict access control wil= l ensure only the Posgres user can read/write to this directory)

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


On Tue, Jul 15, 2025 at 5:06=E2= =80=AFPM Amol Inamdar <amol.aai@gm= ail.com> wrote:
Thanks Tom and Laurenz for the explanation.=C2=A0Let 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 <t= gl@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
--000000000000009ee1063a0bd285--