Re: BUG #15734: Walsender process crashing when executing SHOW ALL;

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: cyberdemn(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15734: Walsender process crashing when executing SHOW ALL;
Date: 2019-04-10 06:04:27
Message-ID: 20190410060427.GB2728@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Apr 08, 2019 at 04:39:03PM +0900, Michael Paquier wrote:
> Problem is origically from 25fff40, and got worse as of 0c8910a0. A
> superuser is able to get the list of parameters, but I can easily see
> the failure when using a plain replication user. A replication user
> is one which can take a full base backup, so he can easily retrieve
> the full list of parameters anyway. What about bypassing the problem
> and just allow WAL sender contexts to always have access to parameter
> values? I don't think that this is much a security issue if one
> thinks about the access to BASE_BACKUP.

After pondering more about this one, allowing replication to have the
same rights as a superuser in this case does not feel completely right
either as this is just a shortcut to bypass the syscache lookups
happening through is_member_of_role(). So attached is a much better
and simple idea: let's just use a transaction context when issuing the
SHOW command so as it is possible to perform cache lookups correctly.
This way, even a replication role is not able to see some parameters
except if the role is a member of pg_read_all_settings, which is more
consistent.

This needs a backpatch down to v10.

Any objections to that?
--
Michael

Attachment Content-Type Size
wal-sender-show.patch text/x-diff 581 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2019-04-10 08:28:55 Re: BUG #15744: Replication slot peak query throwing error for wrong sequence entry for toast chunk
Previous Message PG Bug reporting form 2019-04-10 03:51:07 BUG #15746: cache lookup failed for function in plpgsql block