| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Gilles Darold <gilles(dot)darold(at)dalibo(dot)com> |
| Subject: | Re: current_logfiles not following group access and instead follows log_file_mode permissions |
| Date: | 2019-03-20 05:33:18 |
| Message-ID: | 20190320053318.GC26601@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2019-03-20 05:34:53 | Re: Proposal to suppress errors thrown by to_reg*() |
| Previous Message | Paul Guo | 2019-03-20 05:23:36 | Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown) |