"David G. Johnston" <david.g.johns...@gmail.com> writes:
> Just to make sure we are on the same page as to who IS supposed to be
> "current_user" within these functions - it should be the table owner, right?
If we could make that happen (ie, run the generated-column expressions
as the table owner), it would likely be a sufficient fix for the
security hazard. But we do not have infrastructure for that today.
> This looks like a view...so can we quickly leverage whatever infrastructure
> is used to ensure views are evaluated under the view owner to ensure these
> generated expressions are evaluated as the table owner?
There is no such infrastructure. Views' table accesses are checked as
the view owner, but we don't do anything magic about function calls
within them (which is why selecting from a view carries risk).
You could imagine that every expression taken from a view or virtual
column gets wrapped in a new expression node type RunAsUser, and
I think that that would not be terribly hard to implement.
Unfortunately, it's probably also catastrophic for performance.
It's not even that RunAsUser() in itself would add tons of cycles,
it's that the planner could not treat foo() as being equal to
RunAsUser(foo()), which would prevent all sorts of optimizations.
Maybe we can make that work acceptably, and I would be really happy
if we could. But for sure it's in the realm of "research project"
not "something we can fix post-beta1".
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.
regards, tom lane
