On Wed, 10 Jul 2019 at 16:34, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer <p...@fastcrypt.com> wrote: > >> I'm still a bit conflicted about what to do with search_path as I do > believe this is potentially a security issue. > >> It may be that we always want to report that and possibly back patch it. > > > I don't see that as a feasible option unless we make the logic that > > does the reporting smarter. If it changes transiently inside of a > > security-definer function, and then changes back, my recollection is > > that right now we would report both changes. I think that could cause > > a serious efficiency problem if you are calling such a function in a > > loop. > > And, even more to the point, what's the client side going to do with > the information? If there was a security problem inside the > security-definer function, it's too late. And the client can't do > much about it anyway. > > If we have a configurable GUC_REPORT list, and somebody thinks it's useful > to them to report search_path, I don't wish to stand in their way. > But the argument that this is useful is so tissue-thin that we have no > business imposing the overhead on everybody, much less back-patching it. > > regards, tom lane >
See attached for an initial patch. If this is an acceptable way to go I will add tests and documentation
0001-add-special-startup-parameter-_pq_.guc_report-to-add.patch
Description: Binary data
