MIME-Version: 1.0
From: Amol Inamdar <amol.aai@gmail.com>
Date: Mon, 14 Jul 2025 11:19:55 +0530
Message-ID: <CAGOe9RiRUK9K8gUbsMfg8nWDsM2Fd9py-2oe4VG1Uaggu8fQGA@mail.gmail.com>
Subject: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure
 z/OS NFS (AT-TLS)
To: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000005ea0ed0639dd3bac"
Archived-At: <https://www.postgresql.org/message-id/CAGOe9RiRUK9K8gUbsMfg8nWDsM2Fd9py-2oe4VG1Uaggu8fQGA%40mail.gmail.com>
Precedence: bulk

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

Dear PostgreSQL Community,

I'm currently running PostgreSQL version 16.6 inside a Docker container
(base image: UBI 9), using Docker Compose. The PostgreSQL data directory
is mounted from an NFS volume hosted on a z/OS NFS server.

The environment has a few constraints:

- The NFS server runs on z/OS with AT-TLS enabled.
- It=E2=80=99s a highly secure and access-controlled setup.
- Due to platform restrictions on z/OS, the mounted NFS directory cannot
  be owned by the PostgreSQL user (e.g., `postgres`) inside the container.
- As a result, PostgreSQL fails to start because of the directory
  ownership validation check.

Given the secure nature of the NFS server, I=E2=80=99d like to ask:

1. Is there a supported or recommended way to bypass the ownership
   check on the data directory?
2. What are the potential risks or implications of doing so in a secure
   NFS environment?
3. I'm considering building a custom PostgreSQL image by modifying the
   `miscinit.c` file=E2=80=94specifically, disabling the ownership check in=
 the
   `checkDataDir()` function. Is this a reasonable approach, and are
   there any caveats or unintended side effects I should be aware of?

**Disclaimer**: The z/OS NFS server is secured using AT-TLS and enforces
strict access control policies. My intention is not to weaken
PostgreSQL=E2=80=99s security model, but to adapt to platform-specific
constraints while maintaining overall security integrity.

Any insights, experiences, or alternative suggestions would be greatly
appreciated.

Best regards,
Amol

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

<div dir=3D"ltr">Dear PostgreSQL Community,<br><br>I&#39;m currently runnin=
g PostgreSQL version 16.6 inside a Docker container<br>(base image: UBI 9),=
 using Docker Compose. The PostgreSQL data directory<br>is mounted from an =
NFS volume hosted on a z/OS NFS server.<br><br>The environment has a few co=
nstraints:<br><br>- The NFS server runs on z/OS with AT-TLS enabled.<br>- I=
t=E2=80=99s a highly secure and access-controlled setup.<br>- Due to platfo=
rm restrictions on z/OS, the mounted NFS directory cannot<br>=C2=A0 be owne=
d by the PostgreSQL user (e.g., `postgres`) inside the container.<br>- As a=
 result, PostgreSQL fails to start because of the directory<br>=C2=A0 owner=
ship validation check.<br><br>Given the secure nature of the NFS server, I=
=E2=80=99d like to ask:<br><br>1. Is there a supported or recommended way t=
o bypass the ownership<br>=C2=A0 =C2=A0check on the data directory?<br>2. W=
hat are the potential risks or implications of doing so in a secure<br>=C2=
=A0 =C2=A0NFS environment?<br>3. I&#39;m considering building a custom Post=
greSQL image by modifying the<br>=C2=A0 =C2=A0`miscinit.c` file=E2=80=94spe=
cifically, disabling the ownership check in the<br>=C2=A0 =C2=A0`checkDataD=
ir()` function. Is this a reasonable approach, and are<br>=C2=A0 =C2=A0ther=
e any caveats or unintended side effects I should be aware of?<br><br>**Dis=
claimer**: The z/OS NFS server is secured using AT-TLS and enforces<br>stri=
ct access control policies. My intention is not to weaken<br>PostgreSQL=E2=
=80=99s security model, but to adapt to platform-specific<br>constraints wh=
ile maintaining overall security integrity.<br><br>Any insights, experience=
s, or alternative suggestions would be greatly<br>appreciated.<br><br>Best =
regards, =C2=A0<br>Amol<br></div>

--0000000000005ea0ed0639dd3bac--