On Mon, Oct 22, 2018 at 7:40 PM David Fetter <david@fetter.org> wrote:
>
> On Mon, Oct 22, 2018 at 04:43:52PM +0530, Dilip Kumar wrote:
> > 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.
>
> That's just awful. Were permissions set correctly per their threat
> model, as far as you can tell?
AFAIU, they are having a root table with around 300 child partitions
so they just granted the permission on the main table considering that
should be enough and ended up in the bad plan.
> Was the query constructed correctly?
> Am I understanding correctly that the query as constructed spanned one
> or more partitions that the role querying didn't have permission to
> see?
The query spanned over more than 200 partitions but the role has
permission only on the root table, considering that should be enough
to access child partitions.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
