Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
| От | Jacob Champion |
|---|---|
| Тема | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM |
| Дата | |
| Msg-id | CAOYmi+=Y6GqYyq5o6MOUGY3we9nGO_BRo7ocOE9qFM--bT0b5Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
|
| Список | pgsql-hackers |
On Wed, Dec 3, 2025 at 9:03 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > See also this recent discussion about a --with-copy-program compile flag: > > https://postgr.es/m/flat/CAGRrpza_WUY_jaN4P-xkN%3DTdqfxH%2BeJJazZAo5gg%3DkQoEaQnVw%40mail.gmail.com 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. 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. --Jacob
В списке pgsql-hackers по дате отправления: