On 24.01.2011 20:22, Magnus Hagander wrote:
> On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Another updated patch. Fixed bitrot, and addressed the privilege issue
>> Fujii-san raised here:
>> http://archives.postgresql.org/message-id/4D380560.3040400@enterprisedb.com.
>> I changed the privilege checks so that pg_start/stop_backup() functions
>> require superuser privileges again, but not for a base backup via the
>> replication protocol (replication privilege is needed to establish a
>> replication connection to begin with).
>
> I'm not entirely sure the replication privilege removal is correct.
> Doing that, it's no longer possible to deploy a slave *without* using
> pg_basebackup, unless you are superuser. Do we really want to put that
> restriction back in?
Hmm, I thought we do, I thought that was changed just to make
pg_basebackup work without superuser privileges. But I guess it makes
sense apart from that. So the question is, should 'replication'
privilege be enough to use pg_start/stop_backup(), or should we require
superuser access for that? In any case, replication privilege will be
enough for pg_basebackup.
Ok, I won't touch that. But then we'll need to decide what to do about
Fujii's observation
(http://archives.postgresql.org/pgsql-hackers/2011-01/msg01934.php):
> Both the user with REPLICATION privilege and the superuser can
> call pg_stop_backup. But only superuser can connect to the server
> to cancel online backup during shutdown. The non-superuser with
> REPLICATION privilege cannot. Is this behavior intentional? Or just
> oversight?
> I can't see an explicit check for the user ttempting to do
> pg_stop_backup() when there is a nonexclusive backup running? Maybe
> I'm reading it wrong? The case being when a user has started a backup
> with pg_basebackup but then connects and manually does a
> pg_stop_backup. ISTM it drops us ina codepath that just doesn't do the
> decrement, but also doesn't throw an error?
It throws an error later when it won't find backup_label. For better or
worse, it's always been like that.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
