Restrict lo_import()/lo_export() via SQL permissions not hard-wired checks.
Tom Lane <tgl@sss.pgh.pa.us>
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_JA@mail.gmail.com
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/catalog/system_views.sql | modified | +10 −0 |
| src/backend/libpq/be-fsstubs.c | modified | +0 −16 |
| src/include/catalog/catversion.h | modified | +1 −1 |
| src/include/pg_config_manual.h | modified | +0 −10 |
| src/test/regress/expected/privileges.out | modified | +6 −4 |
| src/test/regress/sql/privileges.sql | modified | +2 −0 |
Discussion
- Simplify ACL handling for large objects and removal of superuser() checks 31 messages · 2017-08-14 → 2017-11-15