On Tue, Feb 21, 2012 at 11:54 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> I don't think that "pure" is sufficient to be leakproof. For example,
> if I have a function which is pure but which takes an unusually long
> time to evaluate for some unique pathological combination of
> arguments, I don't think that it would be considered leakproof.
I think we've made up our mind to largely ignore such cases, though.
There may be information that gets leaked either through the choice of
plan or the time it takes to execute it, but plugging that type of
hole completely is almost impossible. Suppose the security view
filters for rows where user = 'rhaas' and the evil rhaas requests rows
where id = 5. The planner chooses an index-scan on id = 5 and then
applies a filter of user = 'rhaas' to the result. There's probably
some slight timing difference between the case where no id = 5 row
exists, and the case where it exists but does not have user = 'rhaas',
so a sufficiently dedicated hacker might be able to employ a timing
attack to determine the existence of such a row. Also, by jiggering
with page costs and EXPLAIN, they might be able to get some idea of
the number of rows in the table.
I don't believe that this makes the feature useless, though. In most
cases, and especially when using surrogate keys (which I typically do,
whether Josh Berkus likes it or not), the existence of the row is not
a terribly interesting piece of information: it's the content of the
row that's sensitive. Neither table-level security nor column-level
security attempt to prevent you from determining that the table or
column exists; they just hide its contents. And if you need to bar
EXPLAIN so people can't peek at query plans, it's certainly possible
to do that using ProcessUtility_hook. If you're worried about more
subtle timing attacks, you should probably rethink the idea of letting
people log into the database in the first place.
Anyway, to your point, I suppose I might hesitate to mark factorial
leak-proof even if it didn't throw an error on overflow, because the
time it takes to return an answer for larger inputs does grow rather
rapidly. But it's kind of a moot point because the error makes it not
leak-proof anyway. So maybe we're just splitting hairs here, however
we decide to label this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company