On Fri, 2010-06-04 at 10:33 -0400, Tom Lane wrote:
> Hmm ... that's a mighty interesting example, because it shows that any
> well-meaning change in error handling might render seemingly-unrelated
> functions "unsafe". And we're certainly not going to make error
> messages stop showing relevant information just because of this.
Although that looks like a show-stopper, I think it can be worked
around. Errors in operations on security views could simply be caught
and conditionally rewritten. The original error could still appear in
the logs but the full details need not be reported to unprivileged
users.
If that can be done, then we would still need to be able to identify
trusted functions and views used for security purposes, and ensure that
(please excuse my terminology if it is incorrect) untrusted quals do not
get pushed down inside secured views. If all of that can be done along
with the error trapping, then we may have a solution.
My big concern is still about performance, particularly when joining
between multiple security views and other objects. I don't expect to
get security for free but I don't want to see unnecessary barriers to
optimisation.
__
Marc
