Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
| От | Nathan Bossart |
|---|---|
| Тема | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM |
| Дата | |
| Msg-id | aTCfTkk5y6ogVwug@nathan обсуждение исходный текст |
| Ответ на | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
|
| Список | pgsql-hackers |
On Wed, Dec 03, 2025 at 11:35:07AM -0800, Jacob Champion wrote: > Yeah, these conversations tend to get stuck right at this point. > Restricting superuser so that it's somehow not superuser is a huge > (intractable?) undertaking. Doing it a piece at a time doesn't make a > lot of sense if we're not sure that an endpoint exists. But the > ability to escape from the database into the system around it still > seems like a legitimate concern. Yeah, I have a feeling that we're going to continue to receive proposals in this area. Perhaps a good first step is to start listing all the functionality that crosses the OS/database user boundary. Then we might be able to better approximate the effort required and whether we feel comfortable maintaining such a boundary. > A lot of work has been done recently to split apart these privileges > into smaller roles. So what if we just didn't hand out superuser by > default? > > Could initdb be made to instead give you a user with the power to > manage almost all of the database (i.e. pg_maintain/pg_monitor), but > without the power to touch anything outside it or execute arbitrary > code? When you needed true superuser, you could still unlock it from > the outside, and at that point it shouldn't be surprising that you can > escape. IIRC there's been some discussion about that over the years, including in my old thread about compiling out untrusted languages [0]. [0] https://postgr.es/m/flat/20220520225619.GA876272@nathanxps13 -- nathan
В списке pgsql-hackers по дате отправления: