Re: Fixes for missing schema qualifications

On Fri, Nov 30, 2018 at 05:18:09PM +0900, Michael Paquier wrote: > No problem with that either. Thanks Noah for the lookup. And done, without the change for worker_spi. -- Michael signature.asc Description: PGP signature

Re: Fixes for missing schema qualifications

On Thu, Nov 29, 2018 at 10:29:04PM -0800, Noah Misch wrote: > This patch provides no meaningful increment in security or reliability, but it > does improve stylistic consistency. Fine to proceed on those grounds, but > this description doesn't fit. Indeed, you are right. I agree. > > ---

Re: Fixes for missing schema qualifications

On Thu, Nov 29, 2018 at 04:20:24PM +0900, Michael Paquier wrote: > From what I can see in my backlog, this never actually got into the > tree, and it seems to me that fixing those issues is always better than > nothing: > https://www.postgresql.org/message-id/20180309075538.gd9...@paquier.xyz > >

Re: Fixes for missing schema qualifications

On Fri, Mar 16, 2018 at 10:18:59AM +0900, Michael Paquier wrote: > So based on the feedback here is what we could at least do now as a > minimal fix set, in the shape of: > - Patch functions in information_schema.sql, using either operator() or > SET search_path. > - Patch function qualifications

Re: Fixes for missing schema qualifications

On Thu, Mar 15, 2018 at 01:42:08AM -0700, Noah Misch wrote: > Dozens of psql queries call pg_*_is_visible functions, which need the > search_path pertinent for user-entered queries. By itself, (3) doesn't work > for such queries. Even if you implemented (2), using psql with a hostile >

Re: Fixes for missing schema qualifications

On Wed, Mar 14, 2018 at 10:50:38AM +0900, Michael Paquier wrote: > On Sat, Mar 10, 2018 at 08:36:34AM +, Noah Misch wrote: > > This qualifies some functions, but it leaves plenty of unqualified > > operators. > > Yeah, I know that, and i don't have a perfect reply to offer to you. > There

Re: Fixes for missing schema qualifications

On Wed, Mar 14, 2018 at 09:26:15AM +0900, Tatsuo Ishii wrote: > > select [...] where nspname operator(pg_catalog.=) '%s'​ > Next question is, should we update the manual? There are bunch of > places where example queries are shown without schema qualifications. I gave

Re: Fixes for missing schema qualifications

On Tue, Mar 13, 2018 at 07:30:23PM -0700, David G. Johnston wrote: > On Tue, Mar 13, 2018 at 6:50 PM, Michael Paquier > wrote: >> To simplify user's life, we >> could also recommend just to users to issue a ALTER FUNCTION SET >> search_path to fix the problem for all

Re: Fixes for missing schema qualifications

On Wed, Mar 14, 2018 at 10:50:38AM +0900, Michael Paquier wrote: > For the rest, which basically concerns psql, I have been thinking that > actually using 2) would be the most painful approach, still something > which does not impact the user experience, while 3) is easier to > back-patch by

Re: Fixes for missing schema qualifications

On Sat, Mar 10, 2018 at 08:36:34AM +, Noah Misch wrote: > This qualifies some functions, but it leaves plenty of unqualified operators. Yeah, I know that, and i don't have a perfect reply to offer to you. There are a couple of methods that we could use to tackle that: 1) For functions,

Re: Fixes for missing schema qualifications

On Tue, Mar 13, 2018 at 5:26 PM, Tatsuo Ishii wrote: > Next question is, should we update the manual? There are bunch of > places where example queries are shown without schema qualifications. > > I hope that isn't deemed necessary. David J.

Re: Fixes for missing schema qualifications

>> select pg_catalog.count(*) from pg_catalog.pg_namespace where >> pg_catalog.nameeq(nspname, '%s'); >> >> > ​I'd rather write that: > > select [...] where nspname operator(pg_catalog.=) '%s'​ > > Introducing undocumented implementation functions to these queries is > undesirable; and besides,

Re: Fixes for missing schema qualifications

On Tue, Mar 13, 2018 at 5:11 PM, Tatsuo Ishii wrote: > >>> +"select pg_catalog.count(*) " > >>> +"from pg_catalog.pg_namespace > where nspname = '%s'", > >> > >> This qualifies some functions, but it

Re: Fixes for missing schema qualifications

>>> +"select pg_catalog.count(*) " >>> +"from pg_catalog.pg_namespace where >>> nspname = '%s'", >> >> This qualifies some functions, but it leaves plenty of unqualified operators. > > So this should go something like this?

Re: Fixes for missing schema qualifications

>> + "select pg_catalog.count(*) " >> + "from pg_catalog.pg_namespace where >> nspname = '%s'", > > This qualifies some functions, but it leaves plenty of unqualified operators. So this should go something like this?

Re: Fixes for missing schema qualifications

On Sat, Mar 10, 2018 at 03:13:09PM -0300, Alvaro Herrera wrote: > ... and substring() ... substring(A from B for C) gets parsed. -- Michael signature.asc Description: PGP signature

Re: Fixes for missing schema qualifications

Noah Misch wrote: > On Fri, Mar 09, 2018 at 04:55:38PM +0900, Michael Paquier wrote: > > --- a/src/backend/catalog/information_schema.sql > > +++ b/src/backend/catalog/information_schema.sql > > @@ -186,7 +186,7 @@ CREATE FUNCTION _pg_interval_type(typid oid, mod int4) > > RETURNS text > >

Re: Fixes for missing schema qualifications

On Fri, Mar 09, 2018 at 04:55:38PM +0900, Michael Paquier wrote: > --- a/src/backend/catalog/information_schema.sql > +++ b/src/backend/catalog/information_schema.sql > @@ -186,7 +186,7 @@ CREATE FUNCTION _pg_interval_type(typid oid, mod int4) > RETURNS text > AS > $$SELECT >CASE WHEN

Re: Fixes for missing schema qualifications

On Fri, Mar 09, 2018 at 09:35:22AM -0500, David Steele wrote: > These look sane to me. Did you check the back branches for anything > that might not exist in HEAD? I did, but I have not spotted anything extra. Impossible to say that I did not miss one though, such scanning is tiring. -- Michael

Re: Fixes for missing schema qualifications

On 3/9/18 2:55 AM, Michael Paquier wrote: > > In light of CVE-2018-1058, user's applications need to be careful about > the use of schema-unqualified queries. A lookup at the upstream code is > showing four areas which are missing such handling: > - psql has one problem in get_create_object_cmd

Fixes for missing schema qualifications

Hi all, In light of CVE-2018-1058, user's applications need to be careful about the use of schema-unqualified queries. A lookup at the upstream code is showing four areas which are missing such handling: - psql has one problem in get_create_object_cmd which misses twice to qualify