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....@gmail.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....@gmail.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 <t...@sss.pgh.pa.us> wrote:
>>
>>> Laurenz Albe <laurenz.a...@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.  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!

Reply via email to