On Mon, Oct 22, 2018 at 11:22 AM David Fetter <david@fetter.org> wrote:
>
> 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?
One of our customers reported the issue where they have executed the
same query by granting privileges only on the base table vs granting
privileges on all the partitions. The execution time was more than 2
hours in the first case whereas it got completed in 10 seconds in the
second case.
>
> > 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
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
