Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS)

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 AM Amol Inamdar <amol(dot)aai(at)gmail(dot)com> wrote:

> 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 the
> 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 PM Amol Inamdar <amol(dot)aai(at)gmail(dot)com> 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 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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. 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
>

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!