Thread: Side effect of CVE-2017-7484 fix?
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? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
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
Attachment
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, https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.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, > https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.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, > https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.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, >> https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.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, > > https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.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, >>> https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.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, > >>> https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.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.