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!