Re: Does recovery write to backup_label ?

On 2/7/20 8:06 PM, Fujii Masao wrote:
> On Sat, Feb 8, 2020 at 5:05 AM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>>
>> On 2/7/20 2:55 PM, Andres Freund wrote:
>>
>>>> If the file needs to have 0600 permissions, should there be
>>>> a note in the nonexclusive-mode backup docs to say so?
>>>
>>> I'm not convinced that that's useful. The default is that everything
>>> needs to be writable by postgres. The exceptions should be noted if
>>> anything, not the default.
>
> +1

+1.

In theory it would be more secure to only allow rename, but since
Postgres can overwrite any other file in the cluster I don't see much
value in making an exception for this file.

>> Could this arguably be a special case, as most things in the datadir
>> are put there by postgres, but the backup_label is now to be put there
>> (and not even 'there' there, but added as a final step only to a
>> 'backup-copy-of-there' there) by the poor schmuck who reads the
>> non-exclusive backup docs as saying "retrieve this content from
>> pg_stop_backup() and preserve in a file named backup_label" and can't
>> think of any obvious reason to put write permission on a file
>> that preserves immutable history in a backup?
>
> I have no strong objection to add more note about permissions
> of the files that the users put in the data directory. If we really
> do that, it'd be better to note about not only backup_label
> but also other files like tablespace_map, recovery.signal,
> promotion trigger file, etc.

More documentation seems like a good idea, especially since
non-exclusive backup requires the app to choose/set permissions.

Regards,
--
-David
david(at)pgmasters(dot)net