From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) |
Date: | 2025-07-15 06:02:06 |
Message-ID: | cd6eed7ab5ba04826b72e401267c48179b76df11.camel@cybertec.at |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 2025-07-14 at 14:30 -0400, Tom Lane wrote:
> (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.)
Well, if you are using an ext? file system, there is a lost+found
directory where fsck places links to orphaned inodes.
If the PostgreSQL user owns the mount point and wants to use
"initdb" to create a data directory in it, the program will fail
and complain that the directory is not empty. The danger is great
that the user removes the lost+found directory to solve the problem.
True, one could re-create it with "mklost+found", but if a DBA
is uneducated enough to remove the directory in the first place,
the risk is high that he wouldn't think of creating it again,
which is a problem if the file system ever becomes corrupted.
All this doesn't apply to NFS, but it is yet another reason
(apart from the safety of a subdirectory that doesn't exist
on the file system underlying the mount point) why we should
continue to recommend that the data directory be not a mount point.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Durgamahesh Manne | 2025-07-15 10:10:34 | Regarding query optimisation (select for update) |
Previous Message | David G. Johnston | 2025-07-15 05:55:33 | Re: Syntax error needs explanation [RESOLVED] |