Re: Facility for detecting insecure object naming - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Facility for detecting insecure object naming
Date
Msg-id CA+TgmoaiHqg=NsZfdQCqP1BOuL0NW80t-9w_9aTP0=HrVN4XXg@mail.gmail.com
Whole thread Raw
In response to Re: Facility for detecting insecure object naming  (Noah Misch <noah@leadboat.com>)
Responses Re: Facility for detecting insecure object naming
List pgsql-hackers
On Tue, Aug 14, 2018 at 10:44 PM, Noah Misch <noah@leadboat.com> wrote:
> Right.  For what it's worth, the example I permuted upthread might look like
> this in a lexical search path world:
>
> -- Always secure, even if schema usage does not conform to ddl-schemas-patterns
> -- and function trust is disabled or unavailable.
> --
> -- At CREATE EXTENSION time only, subject to denial of service from anyone able
> -- to CREATE in cube schema or earthdistance schema.
> --
> -- Objects in @cube_schema@ are qualified so objects existing in @extschema@ at
> -- CREATE EXTENSION time cannot mask them.
> CREATE FUNCTION latitude(earth)
> RETURNS float8
> LANGUAGE SQL
> IMMUTABLE STRICT
> PARALLEL SAFE
> AS $$SELECT CASE
>   WHEN @cube_schema@.cube_ll_coord($1::@cube_schema@.cube, 3)
>     /
>     earth() < -1 THEN -90::float8
>   WHEN @cube_schema@.cube_ll_coord($1::@cube_schema@.cube, 3)
>     /
>     earth() >  1 THEN  90::float8
>   ELSE degrees(asin(@cube_schema@.cube_ll_coord(
>     $1::@cube_schema@.cube, 3) / earth()))
> END$$;

Could we get rid of the remaining qualification by setting the lexical
search path to @cube_schema@, @extschema@, public?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Facility for detecting insecure object naming
Next
From: Tom Lane
Date:
Subject: Re: libpq should append auth failures, not overwrite