Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
Robert Haas <robertmhaas@gmail.com>,
Feike Steenbergen <feikesteenbergen@gmail.com>,
jian he <jian.universality@gmail.com>,
PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2025-06-03T01:19:20Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Restrict virtual columns to use built-in functions and types
- 0cd69b3d7ef3 18.0 landed
-
Fix virtual generated column type checking for ALTER TABLE
- 49fe1c83ecf3 18.0 landed
-
Expand virtual generated columns in the planner
- 1e4351af329f 18.0 cited
Jeff Davis <pgsql@j-davis.com> writes: > On Thu, 2025-05-29 at 11:12 -0400, Tom Lane wrote: >> Perhaps a compromise is to invent RunAsUser but only apply it to >> virtual columns for now, leaving the view case as a research >> project. Then we aren't destroying the performance of any >> existing queries. > Could we instead check that the expression is safe at the time the > generated column is created? Feels uncomfortably close to solving the halting problem. Maybe we can make a conservative approximation that's good enough to be useful, but I'm not certain. > There are some details to work out. For instance, what happens if a > function starts out as SECURITY DEFINER and then someone changes it > later? Yeah, TOCTOU loopholes would be a huge danger with anything user-defined. I'd kind of want to restrict it to built-in, immutable functions (or maybe stable is enough, not sure). We could reduce the TOCTOU window by making the decision as to whether to wrap in RunAsUser at query rewrite/plan time instead of table creation time. But that would not close the window, so I'm not sure how much it helps. In any case, this doesn't feel like something to be defining and implementing post-beta1. Even if it were not security-critical, the amount of complication involved is well past our standards for what can go in post-feature-freeze. I'm leaning more and more to the position that we ought to revert virtual generated columns for v18 and give ourselves breathing room to design a proper fix for the security hazard. regards, tom lane