From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Andres Freund <andres(at)anarazel(dot)de>, Jeff Davis <pgsql(at)j-davis(dot)com>, 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-30 15:52:20 |
Message-ID: | CA+Tgmoau=K-GCcUR4Ojc7gMTQ8+U=mMF3sGnvqe95ebgfXrJDQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 29, 2022 at 3:46 AM Hannu Krosing <hannuk(at)google(dot)com> wrote:
> terminal 1:
> psql
> hannuk=# select pg_backend_pid();
> pg_backend_pid
> ----------------
> 1749025
> (1 row)
>
> terminal 2:
> echo 1749025 > $PGDATA/allow_superuser
>
> back to terminal 1 still connected to backend with pid 1749025:
> $ CREATE EXTENSION ...
>
> .. and then clean up the sentinel file after, or just make it valid
> for N minutes from creation
I don't think this would be very convenient in most scenarios, and I
think it would also be difficult to implement correctly. I don't think
you can get by with just having superuser() return false sometimes
despite pg_authid.rolsuper being true. There's a lot of subtle
assumptions in the code to the effect that the properties of a session
are basically stable unless some SQL is executed which changes things.
I think if we start injecting hacks like this it may seem to work in
light testing but we'll never get to the end of the bug reports.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-06-30 16:02:21 | Re: margay fails assertion in stats/dsa/dsm code |
Previous Message | Robert Haas | 2022-06-30 15:43:34 | Re: vacuum verbose no longer reveals anything about pins |