Re: Assertion failure in base backup code path
| От | Magnus Hagander |
|---|---|
| Тема | Re: Assertion failure in base backup code path |
| Дата | |
| Msg-id | CABUevEwV6O+C5JoWFJFsgU7aBOZpnmnf3D3BW4TvwUYWScx=ZQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Assertion failure in base backup code path (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: Assertion failure in base backup code path
|
| Список | pgsql-hackers |
On Tue, Dec 24, 2013 at 1:24 PM, Andres Freund <andres@2ndquadrant.com> wrote:
There was a if (!superuser()) check there before as well, that has theOn 2013-12-23 18:28:51 +0100, Magnus Hagander wrote:
> On Dec 19, 2013 12:06 AM, "Andres Freund" <andres@2ndquadrant.com> wrote:
> >
> > Hi Magnus,
> >
> > It looks to me like the path to do_pg_start_backup() outside of a
> > transaction context comes from your initial commit of the base backup
> > facility.
> > The problem is that you're not allowed to do anything leading to a
> > syscache/catcache lookup in those contexts.
>
> I think that may have come with the addition of the replication privilege
> actually but that doesn't change the fact that yes, it appears broken..
same dangers.
I think the correct fix is to move the security check outside of do_pg_start_backup() and leave it to the caller. That means pg_start_backup() for a manual backup. And for a streaming base backup the check has already been made - you can't get through the authentication step if you don't have the required permissions.
Does the attached seem right to you?
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Вложения
В списке pgsql-hackers по дате отправления: