Re: PATCH: Configurable file mode mask

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: Configurable file mode mask
Date: 2018-04-05 06:55:38
Message-ID: 20180405065538.GG1732@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 04, 2018 at 08:03:54PM -0400, David Steele wrote:
> On 4/2/18 2:28 AM, Michael Paquier wrote:
>> The answer is no for me and likely the same for others, but I am raising
>> the point for the archives. Should we relax
>> check_ssl_key_file_permissions() for group permissions by the way from
>> 0600 to 0640 when the file is owned by the user running Postgres? If we
>> don't do that, then SSL private keys will need to be used with 0600,
>> potentially breaking backups... At the same time this reduces the
>> security of private keys but if the administrator is ready to accept
>> group permissions that should be a risk he is ready to accept?
>
> I feel this should be considered in a separate patch. These files are
> not created by initdb so it seems to be an admin/packaging issue. There
> is always the option to locate the certs outside the data directory and
> some distros do that by default.

OK, I agree with your final position. Let's treat it later in a
separate thread, if need be. However this is not really mandatory.

>> I am pretty sure that we want more documentation in pg_basebackup,
>> pg_rewind and pg_resetwal telling that those consider grouping access.
>
> I think this makes sense for pg_basebackup, pg_receivewal, and
> pg_recvlogical so I have added notes for those. Not sure I'm happy with
> the language but at least we have something to bikeshed.
>
> It seems to me that pg_resetwal and pg_rewind should be expected to not
> break the permissions in PGDATA, just as they do now.

OK, I think that I am fine with this logic.

> I decided that the constants were a bit confusing in general. What does
> "default" mean, anyway?

The value that user should have if he decides to not enforce it.

> Instead I have created variables in file_perm.c
> that hold the current file create mode, dir create mode, and mode mask.
> All call sites use those variables (e.g. pg_dir_create_mode), which I
> think are much clear.

Hm. I personally find that even more confusing, especially with
SetDataDirectoryCreatePerm which basically is the same as
SetConfigOption for the backend. In your case pg_dir_create_mode is not
aimed at remaining a constant as you may change it depending on if
grouping is enabled or not... And all the other iterations of such
variables in src/common/ are constants (see NumScanKeywords or
forkNames[] for example), so I cannot see with a good eye this change.

You also forgot a call to SetDataDirectoryCreatePerm or
pg_dir_create_mode remains to its default.

The interface of file_perm.h that you are introducing is not confusing
anymore though..
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2018-04-05 06:56:42 Re: [HACKERS] Add support for tuple routing to foreign partitions
Previous Message David Rowley 2018-04-05 06:54:39 Re: [HACKERS] Runtime Partition Pruning