On Tue, Feb 21, 2012 at 11:54 AM, Jeff Janes <jeff.ja...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
