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
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.
> > --- a/src/
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
>
>
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 I
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
> search_pat
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 are
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 https://www.postgresql.org/d
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 functions, that's easier to
>>
On Tue, Mar 13, 2018 at 6:50 PM, 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 are a couple o
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 minimi
On Tue, Mar 13, 2018 at 05:19:50PM -0700, David G. Johnston wrote:
> On Tue, Mar 13, 2018 at 5:11 PM, Tatsuo Ishii wrote:
>> select pg_catalog.count(*) from pg_catalog.pg_namespace where
>> pg_catalog.nameeq(nspname, '%s');
>>
>>
> I'd rather write that:
>
> select [...] where nspname operator(p
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, enforce
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.
>> 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, i
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 leaves plenty of unqualif
>>> +"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?
>> + "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?
select
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
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
> > AS
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 $1
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
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 w
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 array_remove().
23 matches
Mail list logo
