Re: Fixing insecure security definer functions - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Fixing insecure security definer functions
Date
Msg-id b42b73150702160544v6d82ef0du41acbf5823be41f4@mail.gmail.com
Whole thread Raw
In response to Re: Fixing insecure security definer functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Yoshiyuki Asaba
Date:
Subject: Re: pg_restore fails with a custom backup file
Next
From: Tom Lane
Date:
Subject: Re: Chatter on DROP SOMETHING IF EXISTS