Re: current_logfiles not following group access and instead follows log_file_mode permissions

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: current_logfiles not following group access and instead follows log_file_mode permissions
Date: 2019-01-15 08:55:35
Message-ID: CAJrrPGdL8dfBiX+XzDkvNKjqFOicCJPgMu5wdqJtA4rzN9xEWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 15, 2019 at 4:15 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2019-01-15 09:07:36 Re: Pluggable Storage - Andres's take
Previous Message Michael Paquier 2019-01-15 08:28:01 Re: O_DIRECT for relations and SLRUs (Prototype)