On 24.01.2011 20:22, Magnus Hagander wrote:
On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
Another updated patch. Fixed bitrot, and addressed the privilege issue
Fujii-san raised here:
http://archives.postgresql.org/message-id/4d380560.3040...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
