[pgsql-jp: 38067] Re: Advisory on possibly insecure security definer functions

[ISHIDA Akio]

石田です。

記事に関して1つ気がついたことがあったので。

CREATE FUNCTIONの中で、

oldpath := pg_catalog.current_setting('search_path');
SET search_path TO pg_catalog, public;

としていますが、もしこの関数内でテーブルなどのオブジェクトを
スキーマ修飾無しに作っていると、

create table t1 (...)

は

create table pg_catalog.t1 (...)

と解釈されてしまいます。

search_path で指定したリストの中にpg_catalogが
指定されていない場合は自動的にリストの先頭にpg_catalog
が補われるので、

SET search_path TO public;

と指定するか、あるいはCREATE文では明示的にスキーマ
修飾する必用があると思います。

07/02/21 に Tatsuo Ishii<ishii ＠ sraoss.co.jp> さんは書きました:
> 石井です．
>
> > 片岡です。
> >
> > ISHIDA Akio wrote:
> > > こんにちは。石田@苫小牧市です。
> >
> > > アドバイザリの内容は、SECURITY DEFINERを指定した
> > > pl/pgsql等の関数では、必ず set search_pathを明示的に
> > > 指定しましょうというものです。
> > >
> > > 但し、石井さんの記事にもあるようにSQL関数に関しては
> > > set search_pathによる対応はできません。
> > > SECURITY DEFINERが必要なSQL関数があれば、
> > > pl/pgsqlで書き直してしまうのが良いと思います。
> >
> > スキーマが重要な場合には、単に"スキーマ名.オブジェクト名"で指定すれば
> > いいと思います。
>
> 日経IT Proの記事にも書きましたが，それはほとんど無理です．
>
> 記事中には，
>
> INSERT INTO t1(i) VALUES (mod($1, $2)+10);
>
> -->
>
> INSERT INTO t1(i) VALUES (pg_catalog.mod($1, $2) operator(pg_catalog.+) 10);
>
> のような例をあげました．これだけでも十分面倒ですが，実際にはオペレータ
> とか関数とかデータ型そのほかすべてスキーマ名.オブジェクト名に書き換え
> なければなりません．ですから，単純なWHERE句付きのSELECT:
>
> SELECT * FROM t1 WHERE i  = 'abc'::TEXT AND j < 10;
>
> でさえも，少なくともこんな感じになります．
>
> SELECT * FROM public.t1 WHERE i operator(pg_catalog.=) 'abc'::TEXT AND
> j operator(pg_catalog.<) 10;
>
> 本当は，型も危ないので，TEXT とかスキーマ修飾してあげないといけないの
> かもしれませんが，面倒なので省いています．
>
> # というか，暗黙の型変換とかもあり，その場合は外からスキーマ修飾できな
> # いので，手のうちようがないのでは?あ，でも内部処理は動的にスキーマサー
> # チパスで制御できるからOK?うーん，調査の必要あり．
>
> 実用的でない，と言う点に関してはコアメンバーも同様の意見のようです．
>
> やはり石田さんの言うように，PL/pgSQLに書き直すのがもっとも早いと思いま
> す．
>
> > Subject: Re: [HACKERS] Fixing insecure security definer functions
> > From: Josh Berkus <josh ＠ agliodbs.com>
> > To: pgsql-hackers ＠ postgresql.org
> > Cc: "Zeugswetter Andreas ADI SD" <ZeugswetterA ＠ spardat.at>,
> >         "Peter Eisentraut" <peter_e ＠ gmx.net>
> > Date: Wed, 14 Feb 2007 15:07:24 -0800
> > Reply-To: josh ＠ agliodbs.com
> > Organization: Aglio Database Solutions
> > User-Agent: KMail/1.8
> >
> > Andreas,
> >
> > > Have you considered hardcoding the schema for each object where it was
> > > found at creation time ? This seems more intuitive to me.
> >
> > This isn't practical.  Consider the schema qualification syntax for
> > operators.
> >
> > --
> > --Josh
> >
> > Josh Berkus
> > PostgreSQL @ Sun
> > San Francisco
>
>


-- 
ISHIDA Akio <iakio ＠ mono-space.net/ishida ＠ cycleof5th.com>