Re: Allow replication roles to use file access functions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Allow replication roles to use file access functions
Date
Msg-id 20150902235903.GB17210@awork2.anarazel.de
Whole thread Raw
In response to Re: Allow replication roles to use file access functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Allow replication roles to use file access functions  (Michael Paquier <michael.paquier@gmail.com>)
Re: Allow replication roles to use file access functions  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 2015-09-02 19:48:15 -0400, Tom Lane wrote:
> Just on general principles, this seems like a pretty horrid idea.
> To me replication privilege means the ability to transfer data out of
> the master, not to cause arbitrary state changes on the master.

It's not about the permission to trigger pg_rewind on the master - it's
about being able to run pg_rewind (as the necessary OS user) on the
*standby* when the connection to the primary has only replication rather
than superuser privs.

> Another problem with it is that access to the filesystem is about halfway
> to being superuser anyway, even if it's only read-only access.  It would
> certainly let you read things that one would not expect a replication
> user to be able to read (like files unrelated to Postgres).

Doesn't pg_read_file et al insist that the path is below the data
directorY?

> I don't entirely understand why pg_rewind should be invoking any of these
> functions to begin with.  Isn't it working directly with the disk data,
> with both postmasters shut down?

There's two modes: If both data directories are on the same server both
need to be shut down. If, as it's pretty commonly the case, the "source"
db is on another system the source system must be started (as a
primary). In the second mode all the files that have changed are copied
over a libpq connection.

Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allow replication roles to use file access functions
Next
From: Tomas Vondra
Date:
Subject: Re: Allow a per-tablespace effective_io_concurrency setting