public inbox for [email protected]help / color / mirror / Atom feed
Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) 3+ messages / 3 participants [nested] [flat]
* Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) @ 2025-07-14 19:02 Benjamin Wang <[email protected]> 0 siblings, 2 replies; 3+ messages in thread From: Benjamin Wang @ 2025-07-14 19:02 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Peter J. Holzer <[email protected]>; [email protected] I am not sure whether PostgreSQL depends on system call `fsyncdata` to sync data to disk. If yes, then I don't think it's safe to use NFS. When `fsyncdata` returns success, it doesn't mean the data has really been synced to disk. But if PostgreSQL crashes right after it returns success to clients. Eventually it breaks the D (Durability) of ACID. Benjamin On Mon, Jul 14, 2025 at 7:31 PM Tom Lane <[email protected]> wrote: > "Peter J. Holzer" <[email protected]> writes: > > On 2025-07-14 10:07:20 -0400, Tom Lane wrote: > >> 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. > > > Be careful: There are two different directorys involved in a mount > > point. The one in the parent filesystem and the one in the mounted file > > system. > > True, and the safety requirement really is only that the parent > filesystem's mount-point directory not be writable by us. > But normal practice is that both directories are root-owned, > or at least owned by highly privileged users. > > (I have a vague idea that there are system-level security hazards, > not specific to Postgres, if mount-point directories are publicly > writable. Don't feel like researching that though.) > > regards, tom lane > > > ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) @ 2025-07-14 19:08 David G. Johnston <[email protected]> parent: Benjamin Wang <[email protected]> 1 sibling, 0 replies; 3+ messages in thread From: David G. Johnston @ 2025-07-14 19:08 UTC (permalink / raw) To: Benjamin Wang <[email protected]>; +Cc: Tom Lane <[email protected]>; Peter J. Holzer <[email protected]>; [email protected] On Mon, Jul 14, 2025 at 12:02 PM Benjamin Wang <[email protected]> wrote: > I am not sure whether PostgreSQL depends on system call `fsyncdata` to > sync data to disk. > https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-WAL-SYNC-METHOD David J. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) @ 2025-07-14 19:10 Tom Lane <[email protected]> parent: Benjamin Wang <[email protected]> 1 sibling, 0 replies; 3+ messages in thread From: Tom Lane @ 2025-07-14 19:10 UTC (permalink / raw) To: Benjamin Wang <[email protected]>; +Cc: Peter J. Holzer <[email protected]>; [email protected] Benjamin Wang <[email protected]> writes: > I am not sure whether PostgreSQL depends on system call `fsyncdata` to > sync data to disk. If yes, then I don't think it's safe to use NFS. Well, that's a whole other discussion. The point about mount directories applies to any sort of dismountable storage. (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.) regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-07-14 19:10 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-07-14 19:02 Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) Benjamin Wang <[email protected]> 2025-07-14 19:08 ` David G. Johnston <[email protected]> 2025-07-14 19:10 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox