From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION |
Date: | 2020-05-19 15:11:53 |
Message-ID: | B670A32F-6021-4055-B73F-0F717A401DDA@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 13 Feb 2020, at 23:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
Is this being worked on for the 13 cycle such that it should be an open item?
> Given the current behavior of SET ROLE and SET SESSION AUTHORIZATION,
> I don't actually see any way that we could get these features to
> play together. SET SESSION AUTHORIZATION insists on the originally
> authenticated user being a superuser, so that the documented point of
> --role (to allow you to start the restore from a not-superuser role)
> isn't going to work. I thought about starting to use SET ROLE for
> both purposes, but it checks whether you have role privilege based
> on the session userid, so that a previous SET ROLE doesn't get you
> past that check even if it was a successful SET ROLE to a superuser.
>
> The quick-and-dirty answer is to disallow these switches from being
> used together in pg_restore, and I'm inclined to think maybe we should
> do that in the back branches.
..or should we do this for v13 and back-branches and leave fixing it for 14?
Considering the potential invasiveness of the fix I think the latter sounds
rather appealing at this point in the cycle. Something like the attached
should be enough IIUC.
cheers ./daniel
Attachment | Content-Type | Size |
---|---|---|
pg_restore_role.patch | application/octet-stream | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-05-19 15:12:02 | Trouble with hashagg spill I/O pattern and costing |
Previous Message | Stephen Frost | 2020-05-19 14:54:49 | Re: factorial function/phase out postfix operators? |