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 |
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 |