Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS)

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS)
Дата
Msg-id cd6eed7ab5ba04826b72e401267c48179b76df11.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



В списке pgsql-general по дате отправления: