| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them |
| Date: | 2025-05-29 18:30:29 |
| Message-ID: | 2092388.1748543429@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
> On Thu, 29 May 2025 at 15:44, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> But so far - apart from this feature - we
>> have managed to avoid making it categorically unsafe for the superuser
>> to run "SELECT * FROM table"
> With CREATE RULE [0], a table owner can redefine what happens during
> e.g. SELECT * FROM table.
That's a view, not a table. The distinction is critical in pg_dump,
and we also have restrict_nonsystem_relation_kind which can be used
to prevent accidental reads from views. It would definitely be nice
to have a less hacky answer. But making ordinary tables unsafe to
read absolutely is a quantum jump in insecurity; claiming otherwise
is not helpful.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-05-29 18:55:39 | Re: track generic and custom plans in pg_stat_statements |
| Previous Message | Matthias van de Meent | 2025-05-29 18:24:03 | Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them |