Re: Hardening PostgreSQL via (optional) ban on local file system access
| От | Andres Freund |
|---|---|
| Тема | Re: Hardening PostgreSQL via (optional) ban on local file system access |
| Дата | |
| Msg-id | 20220625010927.mkzgtk237tfzp6yo@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Hardening PostgreSQL via (optional) ban on local file system access (Hannu Krosing <hannuk@google.com>) |
| Список | pgsql-hackers |
Hi, On 2022-06-25 01:23:36 +0200, Hannu Krosing wrote: > Are you claiming that one can manipulate PostgreSQL to do any file > writes directly by manipulating pg_proc to call the functions "in a > wrong way" ? Yes. > My impression was that this was largely fixed via disabling the old > direct file calling convention, but then again I did not pay much > attention at that time :) It got a tad harder, that's all. > So your suggestion would be to also include disabling access to at > least pg_proc for creating C and internal functions and possibly some > other system tables to remove this threat ? No. I seriously doubt that pursuing this makes sense. Fundamentally, if you found a way to escalate to superuser, you're superuser. Superuser can create extensions etc. That's game over. Done. You can of course make postgres drop a few privileges, to make it harder to turn escalation-to-superuser into wider access to the whole system. That could very well make sense - but of course there's quite a few things that postgres needs to do to work, so there's significant limits to what you can do. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: