Re: [COMMITTERS] pgsql: Fix permission tests for views/tables proven empty by constraint

Greg Stark <stark(at)mit(dot)edu> writes:
> If we just reverted your fix and didn't fix it in 9.2 that would also
> fix the crash right? The bug was only that it leaked the fact that the
> view was provably empty from the definition?

Well, it might fail to report a permissions violation when the
not-allowed-to-be-accessed relation could be proven to yield no rows.
I agree that it's a bit hard to call that a security issue as long as
you assume that the attacker has access to the system catalogs; and
even if you don't assume that, being able to discern that there's a
check constraint on some table doesn't seem like a big leakage.

I had originally thought that the issue only occurred in 9.2, but it
turns out that the appendrel form of the problem occurs at least as far
back as 8.4; for example the following admittedly-artificial query

select * from
((select f1 as x from t1 offset 0)
union all
(select f2 as x from t2 offset 0)) ss
where false;

will not throw an error in any current release, even if the caller lacks
select privilege on t1 and/or t2. With manipulation of the outer WHERE
clause, you could find out about the nature of any check constraints on
t1/t2. It's easier to see the bug in 9.2 because you no longer need a
UNION ALL, but that doesn't much change the argument about whether it's
a security issue.

Given that forms of the bug have been around for a long time without
anyone noticing, it might be okay to leave it unfixed in the back
branches.

regards, tom lane