public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ron Johnson <[email protected]>
To: pgsql-generallists.postgresql.org <[email protected]>
Subject: Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS)
Date: Wed, 16 Jul 2025 10:17:43 -0400
Message-ID: <CANzqJaCWkjT85KTCrqt7dsc2PnG_fQ7w53e4Gokuwwe5wAdL9Q@mail.gmail.com> (raw)
In-Reply-To: <CAGOe9RiBSEZo3c8akePA+11HmV1JHx0Lsk57-fGfM0DEf4ekXg@mail.gmail.com>
References: <CAGOe9RiRUK9K8gUbsMfg8nWDsM2Fd9py-2oe4VG1Uaggu8fQGA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAGOe9RirtoXtMJhejo4_V+Si83+c4gfM_E-DH9WqaEBJ9SnfiA@mail.gmail.com>
<CAGOe9RiBSEZo3c8akePA+11HmV1JHx0Lsk57-fGfM0DEf4ekXg@mail.gmail.com>
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>
>>> Laurenz Albe <[email protected]> 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!
view thread (11+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS)
In-Reply-To: <CANzqJaCWkjT85KTCrqt7dsc2PnG_fQ7w53e4Gokuwwe5wAdL9Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox