From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Pang <robertpang(at)google(dot)com> |
Subject: | Re: Hardening PostgreSQL via (optional) ban on local file system access |
Date: | 2022-06-25 01:09:27 |
Message-ID: | 20220625010927.mkzgtk237tfzp6yo@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-06-25 01:30:26 | Re: making relfilenodes 56 bits |
Previous Message | Andres Freund | 2022-06-25 01:05:51 | Re: [PATCH] Optimize json_lex_string by batching character copying |