Re: current_logfiles not following group access and instead followslog_file_mode permissions - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: current_logfiles not following group access and instead followslog_file_mode permissions
Date
Msg-id CAJrrPGdL8dfBiX+XzDkvNKjqFOicCJPgMu5wdqJtA4rzN9xEWg@mail.gmail.com
Whole thread Raw
In response to Re: current_logfiles not following group access and instead followslog_file_mode permissions  (Michael Paquier <michael@paquier.xyz>)
Responses Re: current_logfiles not following group access and instead follows log_file_mode permissions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Tue, Jan 15, 2019 at 4:15 PM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Jan 15, 2019 at 03:08:41PM +1100, Haribabu Kommi wrote:
> current_logfiles is a meta data file, that stores the current log writing
> file, and this file presents in the data directory. This file
> doesn't follow the group access mode set at the initdb time, but it
> follows the log_file_mode permissions.
>
> Without group access permissions, backup with group access can lead to
> failure.  Attached patch fix the problem.

initdb enforces log_file_mode to 0640 when using the group mode, still
if one enforces the parameter value then current_logfiles would just
stick with it.  This is not really user-friendly.  This impacts also
normal log files as these get included in base backups if the log path
is within the data folder (not everybody uses an absolute path out of
the data folder for the logs).

we got this problem when the log_file_mode is set 0600 but the database
file are with group access permissions. In our scenario, the log files are
outside the data folder, so we faced the problem with current_logfiles
file.
 
One way to think about this is that we may want to worry also about
normal log files and document that one had better be careful with the
setting of log_file_mode?  Still, as we are talking about a file
aiming at storing meta-data for log files, something like what you
suggest can make sense.

Yes, with log_file_mode less than 0640 containing the log files inside
the data directory can leads to backup failure. Yes, providing extra
information about group access when log_file_mode is getting chosen.

Another option is how about not letting user to choose less than 0640
when the group access mode is enabled?

 
When discussing about pg_current_logfile(), I raised the point about
not including as well in base backups which would also address the
problem reported here.  However we decided to keep it because it can
be helpful to know what's the last log file associated to a base
backup for debugging purposes:
https://www.postgresql.org/message-id/50b58f25-ab07-f6bd-7a68-68f29f214ce9@dalibo.com

Instead of what you are proposing, why not revisiting that and just
exclude the file from base backups.  I would be in favor of just doing
that instead of switching the file's permission from log_file_mode to
pg_file_create_mode.

I am not sure how much useful having the details of the log file in the backup.
It may be useful when there is any problem with backup.

Excluding the file in the backup can solve the problem of backup by an
unprivileged user. Is there any scenarios it can cause problems if it
doesn't follow the group access mode?

Regards,
Haribabu Kommi
Fujitsu Australia

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: O_DIRECT for relations and SLRUs (Prototype)
Next
From: Amit Khandekar
Date:
Subject: Re: Pluggable Storage - Andres's take