Restrict lo_import()/lo_export() via SQL permissions not hard-wired checks.
While it's generally unwise to give permissions on these functions to anyone but a superuser, we've been moving away from hard-wired permission checks inside functions in favor of using the SQL permission system to control access. Bring lo_import() and lo_export() into compliance with that approach. In particular, this removes the manual configuration option ALLOW_DANGEROUS_LO_FUNCTIONS. That dates back to 1999 (commit 4cd4a54c8); it's unlikely anyone has used it in many years. Moreover, if you really want such behavior, now you can get it with GRANT ... TO PUBLIC instead. Michael Paquier Discussion: https://postgr.es/m/cab7npqrhmnoybetnc_2ejsuzsm00z+bwkv9sy6tnvsd5gwt...@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/5ecc0d738e5864848bbc2d1d97e56d5846624ba2 Modified Files -------------- src/backend/catalog/system_views.sql | 10 ++++++++++ src/backend/libpq/be-fsstubs.c | 16 ---------------- src/include/catalog/catversion.h | 2 +- src/include/pg_config_manual.h | 10 ---------- src/test/regress/expected/privileges.out | 10 ++++++---- src/test/regress/sql/privileges.sql | 2 ++ 6 files changed, 19 insertions(+), 31 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
