Re: Fixing insecure security definer functions

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Fixing insecure security definer functions
Дата
Msg-id b42b73150702160544v6d82ef0du41acbf5823be41f4@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fixing insecure security definer functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2/15/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
> > yikes!
>
> > If you guys go through with forcing functions to attach to objects
> > when they are created, it will break almost every project I've ever
> > worked on :(.  The schema/function combo fits into all kinds of de
> > facto partitioning strategies and organization methods.
>
> If you read a bit further, I did suggest providing an option to retain
> the current behavior.  I don't think it should be the default though.

Yeah, I saw that, but the issue is really deeper, functions that
create functions, etc. changing the default behavior affects how
functions work in a really fundamental way...all pl/pgsql code that
can float over schemas would have to be checked.  In the worst case,
this could mean converting large libraries to dynamic sql or creating
thousands of additional functions...ugh.

Maybe there could be a GUC setting(function default function schema
path=current path/path null)?  It would seem only appropriate to have
security definer raise a warning/error for path null though.  Then we
could debate about how that should be set by default but nobody really
loses that argument.

merlin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yoshiyuki Asaba
Дата:
Сообщение: Re: pg_restore fails with a custom backup file
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Chatter on DROP SOMETHING IF EXISTS