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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
