On 3/18/17 3:57 PM, Robert Haas wrote:
On Wed, Mar 15, 2017 at 3:00 AM, Tsunakawa, Takayuki
wrote:
I'm on David's side, too. I don't postmaster to always scan all files at
startup.
+1. Even just doing it during crash recovery, it can take a
regrettably long time on machines with tons of re
On Wed, Mar 15, 2017 at 3:00 AM, Tsunakawa, Takayuki
wrote:
> I'm on David's side, too. I don't postmaster to always scan all files at
> startup.
+1. Even just doing it during crash recovery, it can take a
regrettably long time on machines with tons of relations and a very
slow disk. I've bee
On 3/15/17 3:00 AM, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
>>> But it might be worth thinking about whether we want to encourage
>>> people to do manual chmod's at all; that's fairly easy to get
On 3/15/17 1:56 AM, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
>> Sure, but having the private key may allow them to get new data from the
>> server as well as the data from the backup.
>
> You are
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
> > But it might be worth thinking about whether we want to encourage
> > people to do manual chmod's at all; that's fairly easy to get wrong,
> > particularly given the difference in X
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
> Sure, but having the private key may allow them to get new data from the
> server as well as the data from the backup.
You are right. My rough intent was that the data is stolen anyw
On 3/13/17 3:03 PM, Tom Lane wrote:
> David Steele writes:
>> On 3/13/17 2:16 PM, Tom Lane wrote:
>>> I also don't especially want to have to analyze cases like "what
>>> happens if user initdb'd with mask X but then changes the GUC and
>>> restarts the postmaster?". Maybe the right thing is to n
On 3/14/17 4:23 AM, Tsunakawa, Takayuki wrote:
> From: David Steele [mailto:da...@pgmasters.net]
3.The default location of the SSL key file is $PGDATA, so the permission
>> of the key file is likely to become 0640. But the current postgres requires
>> it to be 0600. See src/backend/libpq/be-
From: David Steele [mailto:da...@pgmasters.net]
> >> 3.The default location of the SSL key file is $PGDATA, so the permission
> of the key file is likely to become 0640. But the current postgres requires
> it to be 0600. See src/backend/libpq/be-secure-openssl.c.
> >
> > Yes, that needs to be add
David Steele writes:
> On 3/13/17 2:16 PM, Tom Lane wrote:
>> I also don't especially want to have to analyze cases like "what
>> happens if user initdb'd with mask X but then changes the GUC and
>> restarts the postmaster?". Maybe the right thing is to not expose
>> this as a GUC at all, but dri
On 3/13/17 2:16 PM, Tom Lane wrote:
> David Steele writes:
>> On 3/13/17 1:03 PM, Tom Lane wrote:
>>> TBH, the fact that we're relying on 0600 mode for considerations such
>>> as these makes me tremendously afraid of this whole patch. I think that
>>> the claimed advantages are not anywhere near
David Steele writes:
> On 3/13/17 1:03 PM, Tom Lane wrote:
>> TBH, the fact that we're relying on 0600 mode for considerations such
>> as these makes me tremendously afraid of this whole patch. I think that
>> the claimed advantages are not anywhere near worth the risk that somebody
>> is going t
Hi Tom,
On 3/13/17 1:03 PM, Tom Lane wrote:
> David Steele writes:
>> At miscinit.c:893:
>
>> /* We can treat the EPERM-error case as okay because that error implies
>> that the existing process has a different userid than we do, which means
>> it cannot be a competing postmaster. A postmaster
Hi Tom,
On 3/13/17 1:13 PM, Tom Lane wrote:
> ... oh, and now that I've actually looked at the patch, I think it's
> a seriously bad idea to proceed by removing the mode parameter to
> PathNameOpenFile et al. That's basically doubling down on an assumption
> that there are NO places in the backen
... oh, and now that I've actually looked at the patch, I think it's
a seriously bad idea to proceed by removing the mode parameter to
PathNameOpenFile et al. That's basically doubling down on an assumption
that there are NO places in the backend, and never will be any, in which
we want to create
David Steele writes:
> At miscinit.c:893:
> /* We can treat the EPERM-error case as okay because that error implies
> that the existing process has a different userid than we do, which means
> it cannot be a competing postmaster. A postmaster cannot successfully
> attach to a data directory owne
On 3/10/17 8:34 AM, Stephen Frost wrote:
> Greetings,
>
> * Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote:
>> From: pgsql-hackers-ow...@postgresql.org
>>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
>>> PostgreSQL currently requires the file mode mask (umask)
On 3/10/17 8:12 AM, Stephen Frost wrote:
> Peter,
>
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> On 2/28/17 20:58, David Steele wrote:
>>> This patch introduces a new initdb param, -u/-file-mode-mask, and a new
>>> GUC, file_mode_mask, to allow the default mode of files and di
Greetings,
* Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote:
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
> > PostgreSQL currently requires the file mode mask (umask) to be 0077.
> > However, this precludes the pos
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2/28/17 20:58, David Steele wrote:
> > This patch introduces a new initdb param, -u/-file-mode-mask, and a new
> > GUC, file_mode_mask, to allow the default mode of files and directories
> > in the $PGDATA directory to be mod
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
> PostgreSQL currently requires the file mode mask (umask) to be 0077.
> However, this precludes the possibility of a user in the postgres group
> performing a backup (or whatever). Now
On 2/28/17 20:58, David Steele wrote:
> This patch introduces a new initdb param, -u/-file-mode-mask, and a new
> GUC, file_mode_mask, to allow the default mode of files and directories
> in the $PGDATA directory to be modified.
The postmaster.pid file appears not to observe the configured mask.
On 3/6/17 8:17 AM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 7:38 AM, Tom Lane wrote:
>> Simon Riggs writes:
>>> On 1 March 2017 at 01:58, David Steele wrote:
PostgreSQL currently requires the file mode mask (umask) to be 0077.
However, this precludes the possibility of a user in the
On 3/6/17 8:50 AM, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>>> to allow the default mode of files and directories
>>> in the $PGDATA directory to be modified.
>>
>> Are you saying if this is changed all files/directories will be
>> changed to the new mode?
>
> No, new
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Simon Riggs writes:
> > On 1 March 2017 at 01:58, David Steele wrote:
> >> PostgreSQL currently requires the file mode mask (umask) to be 0077.
> >> However, this precludes the possibility of a user in the postgres group
> >> performing a backup (or
Greetings,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 1 March 2017 at 01:58, David Steele wrote:
> > PostgreSQL currently requires the file mode mask (umask) to be 0077.
> > However, this precludes the possibility of a user in the postgres group
> > performing a backup (or whatever). Now
On Mon, Mar 6, 2017 at 7:38 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On 1 March 2017 at 01:58, David Steele wrote:
>>> PostgreSQL currently requires the file mode mask (umask) to be 0077.
>>> However, this precludes the possibility of a user in the postgres group
>>> performing a backup (or
Simon Riggs writes:
> On 1 March 2017 at 01:58, David Steele wrote:
>> PostgreSQL currently requires the file mode mask (umask) to be 0077.
>> However, this precludes the possibility of a user in the postgres group
>> performing a backup (or whatever). Now that
>> pg_start_backup()/pg_stop_backu
On 1 March 2017 at 01:58, David Steele wrote:
> PostgreSQL currently requires the file mode mask (umask) to be 0077.
> However, this precludes the possibility of a user in the postgres group
> performing a backup (or whatever). Now that
> pg_start_backup()/pg_stop_backup() privileges can be deleg
PostgreSQL currently requires the file mode mask (umask) to be 0077.
However, this precludes the possibility of a user in the postgres group
performing a backup (or whatever). Now that
pg_start_backup()/pg_stop_backup() privileges can be delegated to an
unprivileged user, it makes sense to also al
30 matches
Mail list logo