On Tue, 2009-10-20 at 10:32 -0400, Tom Lane wrote:
> That's only sane if you are 100% certain that there could not be a
> security issue arising from the change of behavior. Otherwise someone
> could for instance subvert a security-definer function by running it
> under the setting it wasn't written for. Personally I am not 100%
> certain of that.
This is pretty much equivalent to the issue of setting search_path for
security definer functions. Such settings that affect the semantics of
code should be overridden to a know safe value by such functions.
Still, making the setting SUSET will be very impractical. The superuser
will have to ensure that all current and future functions on the
installation conform to the setting that is chosen. This is pretty much
impossible. The other choice is to uglify every function with an
explicit setting. So in practice the only convenient and robust choice
is to leave it as is.
The correct solution, IMO, is that security definer functions need to
save the set of deemed-security-critical parameters automatically at
function creation time. Since we don't do that currently, I'd guess
that 50% of security definer functions out there are still unsafe about
search_path.