| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, Robert Haas <robertmhaas(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 23:32:01 |
| Message-ID: | aDjucQTzvTlAT63f@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 29, 2025 at 02:15:22PM -0400, Tom Lane wrote:
> Feike Steenbergen <feikesteenbergen(at)gmail(dot)com> writes:
> > pg_restore may have issues though, as it will run these functions
> > for GENERATED STORED columns?
>
> pg_restore is already fairly exposed, as it will run tables' CHECK
> constraints, index expressions, etc. I don't think GENERATED STORED
> makes that picture much worse.
>
> As Robert said upthread, it would be nice to make all this more
> secure. But it'd presumably involve user-visible semantics changes
> along with the performance worries I mentioned. It's a dauntingly
> large task...
I spent some time thinking about the above email. First, this is on the
public hackers list, so it explains known security deficiencies. Do we
document these somewhere? I don't see them in the pg_dump or pg_restore
manual pages.
Second, I agree adding a SELECT security deficiency is certainly worse,
but how are we expecting people to restore databases securely with these
known deficiencies?
Effectively, what good is our security system if it is just delaying
someone from getting superuser privileges in case of a dump/restore?
(Yeah, that's me, Mr. Sunshine. ;-) )
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-05-29 23:34:49 | Re: Add comment explaining why queryid is int64 in pg_stat_statements |
| Previous Message | Michael Paquier | 2025-05-29 23:30:54 | Re: Persist injection points across server restarts |