Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().

At Sun, 24 Oct 2021 09:50:58 -0700, Jeff Davis <pgsql(at)j-davis(dot)com> wrote in
> On Sat, 2021-10-23 at 20:42 +0000, Bossart, Nathan wrote:
> > The predefined roles documentation notes
> > that members of pg_signal_backend cannot signal superuser-owned
> > backends, but AFAICT pg_log_backend_memory_contexts() has no such
> > restriction at the moment. Should we add this?
>
> Added, good catch.
>
> > This is unrelated to this patch, but should we also consider opening
> > up pg_reload_conf() and pg_rotate_logfile() to members of
> > pg_signal_backend? Those are the other "server signaling functions"
> > I
> > see in the docs.
>
> Those are actually signalling the postmaster, not an ordinary backend.
> Also, those functions are already GRANTable, so I think we should leave
> them as-is.

I'm afraid that it might be wrong that all backend-signalling features
are allowed by that priviledge. pg_signal_backends is described in
the doc as:

https://www.postgresql.org/docs/devel/predefined-roles.html

> Signal another backend to cancel a query or terminate its session.

Here, the term "signal" there seems to mean interrupting something on
that session or the session itself. Addition to that I don't think
"terminate a session or the query on a session" and "log something on
another session" and "rotate log file" don't fall into the same
category in a severity view.

In other words, I don't think pg_signal_backends is not meant to
control "log something on another session" or "rotate log file". It's
danger that if we allow somewone to rotate log files, that means to
allow same user to terminate another session.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center