On Mon, Oct 22, 2018 at 11:10:09AM +0530, Dilip Kumar wrote: > As part of the security fix > (e2d4ef8de869c57e3bf270a30c12d48c2ce4e00c), we have restricted the > users from accessing the statistics of the table if the user doesn't > have privileges on the table and the function is not leakproof. > Now, as a side effect of this, if the user has the privileges on the > root partitioned table but does not have privilege on the child > tables, the user will be able to access the data of the child table > but it won't be able to access the statistics of the child table.
Do we have any kind of quantitative idea of how much worse query performance gets with this blind spot? > This may result in a bad plan. I am not sure what should be the > fix. Should we allow to access the statistics of the table if a > user has privilege on its parent table? In threat modeling terms, access to the statistics is an information leak. If we just say "too bad" to the people who care a lot about slowing information leaks, I'm guessing that would make them very unhappy. Since the access controls are built for those people, I'd say that we should prioritize performance optimizations for cases when people haven't explicitly decided to trade performance for lower information leak rates, which is to say for people who haven't put those access controls on in the first place. That's just my take, though. Another GUC to control this, perhaps? Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate