| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org> |
| Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cached plans and statement generalization |
| Date: | 2017-04-25 22:38:23 |
| Message-ID: | CAKFQuwYMzpLF_mPNsfacMptx74++aVkiBU3=iEgiTDtMb3RmBA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 25, 2017 at 3:24 PM, David Fetter <david(at)fetter(dot)org> wrote:
> I don't have an exploit yet. What concerns me is attackers' access to
> what is in essence the ability to poke at RULEs when they only have
> privileges to read.
>
If they want to see how it works they can read the source code. In terms
of runtime data it would limited to whatever the session itself created.
In most cases the presence of the cache would be invisible. I suppose it
might appear if one were to explain a query, reset the session, explain
another query and then re-explain the original. If the chosen plan in the
second pass differed because of the presence of the leading query it would
be noticeable but not revealing. Albeit I'm a far cry from a security
expert...
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Doug Doole | 2017-04-25 22:48:16 | Re: Cached plans and statement generalization |
| Previous Message | Andres Freund | 2017-04-25 22:34:48 | Re: Cached plans and statement generalization |