| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Gurjeet Singh <gurjeet(at)singh(dot)im>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Fix search_path for all maintenance commands |
| Date: | 2023-10-27 23:04:26 |
| Message-ID: | dfdd53fcf4be43777c81bf66ef725e28b3169ce1.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2023-07-21 at 15:32 -0700, Jeff Davis wrote:
> Attached is a new version.
Do we still want to do this?
Right now, the MAINTAIN privilege is blocking on some way to prevent
malicious users from abusing the MAINTAIN privilege and search_path to
acquire the table owner's privileges.
The approach of locking down search_path during maintenance commands
would solve the problem, but it means that we are enforcing search_path
in some contexts and not others. That's not great, but it's similar to
what we are doing when we ignore SECURITY INVOKER and run the function
as the table owner during a maintenance command, or (by default) for
subscriptions.
My attempts to more generally try to lock down search_path for
functions attached to tables didn't seem to get much consensus, so if
we do make an exception to lock down search_path for maintenance
commands only, it would stay an exception for the foreseeable future.
Thoughts?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2023-10-27 23:05:33 | Re: [PATCH v1] [doc] polish the comments of reloptions |
| Previous Message | Bruce Momjian | 2023-10-27 22:55:12 | Re: [PATCH] minor bug fix for pg_dump --clean |