Side effect of CVE-2017-7484 fix?

Greetings,

* Dilip Kumar (dilipbalaut@gmail.com) 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. 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?

Yes... If the user has access to the parent table then they can see the
child tables, so they should be able to see the statistics on them.

That's my 2c on a quick review, at least.

Thanks!

Stephen

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

Hi,

On 2018/10/22 14:41, Stephen Frost wrote:

Greetings,

* Dilip Kumar (dilipbalaut@gmail.com) 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. 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?

Yes... If the user has access to the parent table then they can see the
child tables, so they should be able to see the statistics on them.

Yeah, but I'd think only if access the child tables are being accessed via
the parent table.

So, maybe, statistic_proc_security_check() added by that commit should
return true if IS_OTHER_REL(vardata->rel)?

Thanks,
Amit

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

On Mon, Oct 22, 2018 at 12:05 PM Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:

Hi,

On 2018/10/22 14:41, Stephen Frost wrote:

Greetings,

* Dilip Kumar (dilipbalaut@gmail.com) 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. 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?

Yes... If the user has access to the parent table then they can see the
child tables, so they should be able to see the statistics on them.

Yeah, but I'd think only if access the child tables are being accessed via
the parent table.

I agree.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Dilip Kumar <dilipbalaut@gmail.com> writes:

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. This may result
in a bad plan.

This was complained of already,
/messages/by-id/3876.1531261875@sss.pgh.pa.us

regards, tom lane

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? 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?

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

On Mon, Oct 22, 2018 at 7:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dilip Kumar <dilipbalaut@gmail.com> writes:

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. This may result
in a bad plan.

This was complained of already,
/messages/by-id/3876.1531261875@sss.pgh.pa.us

regards, tom lane

Ok, I see. Thanks.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

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

On Mon, Oct 22, 2018 at 9:47 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dilip Kumar <dilipbalaut@gmail.com> writes:

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. This may result
in a bad plan.

This was complained of already,
/messages/by-id/3876.1531261875@sss.pgh.pa.us

I guess you never followed up on that part, though. Any special
reason for that, or just lack of round tuits?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:

On Mon, Oct 22, 2018 at 9:47 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

This was complained of already,
/messages/by-id/3876.1531261875@sss.pgh.pa.us

I guess you never followed up on that part, though. Any special
reason for that, or just lack of round tuits?

The latter.

regards, tom lane

On Wed, Oct 24, 2018 at 04:01:29PM -0400, Robert Haas wrote:

On Mon, Oct 22, 2018 at 9:47 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dilip Kumar <dilipbalaut@gmail.com> writes:

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. This may result
in a bad plan.

This was complained of already,
/messages/by-id/3876.1531261875@sss.pgh.pa.us

I guess you never followed up on that part, though. Any special
reason for that, or just lack of round tuits?

Should this be added as a TODO item?

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

Bruce Momjian <bruce@momjian.us> writes:

On Wed, Oct 24, 2018 at 04:01:29PM -0400, Robert Haas wrote:

This was complained of already,
/messages/by-id/3876.1531261875@sss.pgh.pa.us

I guess you never followed up on that part, though. Any special
reason for that, or just lack of round tuits?

Should this be added as a TODO item?

Huh? We dealt with that a long time ago, cf 553d2ec27.

regards, tom lane

On Thu, Nov 9, 2023 at 06:44:42PM -0500, Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

On Wed, Oct 24, 2018 at 04:01:29PM -0400, Robert Haas wrote:

This was complained of already,
/messages/by-id/3876.1531261875@sss.pgh.pa.us

I guess you never followed up on that part, though. Any special
reason for that, or just lack of round tuits?

Should this be added as a TODO item?

Huh? We dealt with that a long time ago, cf 553d2ec27.

Oh, okay, thanks.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.