Re: current_logfiles not following group access and instead follows log_file_mode permissions
Haribabu Kommi <kommi.haribabu@gmail.com>
From: Haribabu Kommi <kommi.haribabu@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Gilles Darold <gilles.darold@dalibo.com>
Date: 2019-03-21T01:41:16Z
Lists: pgsql-hackers
Attachments
- 0001-Adjust-current_logfiles-file-permissions_v2.patch (application/octet-stream) patch v2-0001
On Wed, Mar 20, 2019 at 4:33 PM Michael Paquier <michael@paquier.xyz> wrote: > On Fri, Mar 15, 2019 at 06:51:37PM +1100, Haribabu Kommi wrote: > > IMO, this update is just a recommendation to the user, and sometimes it > is > > still possible that there may be strict permissions for the log file > > even the data directory is allowed for the group access. So I feel > > it is still better to update the permissions of the current_logfiles > > to the database files permissions than log file permissions. > > I was just reading again this thread, and the suggestions that > current_logfiles is itself not a log file is also a sensible > position. I was just looking at the patch that you sent at the top of > the thread here: > > https://www.postgresql.org/message-id/CAJrrPGcEotF1P7AWoeQyD3Pqr-0xkQg_Herv98DjbaMj+naozw@mail.gmail.com > Thanks for the review. > And actually it seems to me that you have a race condition in that > stuff. I think that you had better use umask(), then fopen, and then > once again umask() to put back the previous permissions, removing the > extra chmod() call. > Changed the patch to use umask() instead of chmod() according to your suggestion. updated patch attached. Regards, Haribabu Kommi Fujitsu Australia
Commits
-
Make current_logfiles use permissions assigned to files in data directory
- 7d7435c5c505 11.3 landed
- 276d2e6c2d81 12.0 landed