From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Subject: | Re: Misplaced superuser check in pg_log_backend_memory_contexts() |
Date: | 2021-06-06 07:13:12 |
Message-ID: | 20210606071312.cgps4ufp52btdnbb@nol |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jun 06, 2021 at 03:53:10PM +0900, Michael Paquier wrote:
>
> While reading the code of pg_log_backend_memory_contexts(), I have
> been surprised to see that the code would attempt to look at a PROC
> entry based on the given input PID *before* checking if the function
> has been called by a superuser. This does not strike me as a good
> idea as this allows any users to call this function and to take
> ProcArrayLock in shared mode, freely.
It doesn't seem like a huge problem as at least GetSnapshotData also acquires
ProcArrayLock in shared mode. Knowing if a specific pid is a postgres backend
or not isn't privileged information either, and anyone can check that using
pg_stat_activity as an unprivileged user (which will also acquire ProcArrayLock
in shared mode).
>
> It seems to me that we had better check for a superuser at the
> beginning of the function, like in the attached.
However +1 for the patch, as it seems more consistent to always get a
permission failure if you're not a superuser.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2021-06-06 07:32:20 | Re: SQL-standard function body |
Previous Message | Michael Paquier | 2021-06-06 06:53:10 | Misplaced superuser check in pg_log_backend_memory_contexts() |