From: | Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log files and permissions |
Date: | 2010-07-13 12:16:08 |
Message-ID: | 4C3C5908.2010909@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Itagaki Takahiro wrote:
> I think the patch is almost ready for committer except the following
> three issues:
>
> 2010/7/13 Fujii Masao <masao(dot)fujii(at)gmail(dot)com>:
>>> + if (!*value || *endptr || file_mode < 0 || file_mode > 0777)
>> The sticky bit cannot be set via log_file_mode. Is this intentional?
Yes -- I don't think there is a use case for sticky or setuid bits on log
files, even allowing execute is questionable.
> We should also check the value not to be something like 0699.
> How about checking it with (file_mode & ~0666) != 0 ?
Aha, that would ensure that the execute bit is not specified. Works for me.
The 0699 and other invalid octal values are caught by strtol()
>>> +#ifndef WIN32
>>> + chmod(filename, Log_file_mode);
>>> +#endif
>> Don't we need to check the return value of chmod()?
>
> I prefer umask() rather than chmod() here.
>
Converted to umask()
>>> +const char *show_log_file_mode(void);
>> You forgot to write the show_log_file_mode()? I was not able to find that
>> in the patch.
>
> I want show_log_file_mode to print the setting value in octal format.
>
I've now (re)added the show_log_file_mode(). It used to be there, but then
at some point I decided to display the value "as-is".
While going through it, I moved the _setmode() call for win32 to logfile_open().
regards,
Martin
Attachment | Content-Type | Size |
---|---|---|
log-file-mode.patch | text/x-diff | 10.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-07-13 13:29:16 | Re: dblink regression failure in HEAD |
Previous Message | Stephen Frost | 2010-07-13 11:05:21 | Re: dblink regression failure in HEAD |