Re: Hardening PostgreSQL via (optional) ban on local file system access
От | Robert Haas |
---|---|
Тема | Re: Hardening PostgreSQL via (optional) ban on local file system access |
Дата | |
Msg-id | CA+Tgmoau=K-GCcUR4Ojc7gMTQ8+U=mMF3sGnvqe95ebgfXrJDQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hardening PostgreSQL via (optional) ban on local file system access (Hannu Krosing <hannuk@google.com>) |
Ответы |
Re: Hardening PostgreSQL via (optional) ban on local file system access
|
Список | pgsql-hackers |
On Wed, Jun 29, 2022 at 3:46 AM Hannu Krosing <hannuk@google.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
В списке pgsql-hackers по дате отправления: