log files and permissions

With logging_collector enabled, all the postgres log files are created with
mode 0600. This makes life complicated if users other than "postgres" need
to be able to examine the log files as well. Common example of this is when the
database runs under "postgres" user and DBA-s have named accounts. In order to
examine the log files the DBA then has to go through extra steps to sudo to
"postgres" or equivalent. Another example would be a monitoring script that
runs as an unprivileged user but needs to tail the log files.

It'd be convenient if the log files would have group read access. Then we could
make all the DBA or monitoring users members of the postgres group and they'd
have direct access to the logs. However, as the "group read" is not likely a
universally correct setting, the creation mode needs to be configurable.

Attached is a patch that adds a GUC "log_file_mode" which allows to specify
the creation mode for the log files. Presently it lacks documentation, which
I'll add if the idea is generally acceptable.

PS. I have no idea how all of this would work on Windows, maybe it's not
event relevant there?

regards,
Martin

Martin Pihlak wrote:
> Attached is a patch that adds a GUC "log_file_mode" which allows to specify
> the creation mode for the log files. Presently it lacks documentation, which
> I'll add if the idea is generally acceptable.
>

Now it really is attached.

regards,
Martin

Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> writes:
> It'd be convenient if the log files would have group read access. Then we could
> make all the DBA or monitoring users members of the postgres group and they'd
> have direct access to the logs. However, as the "group read" is not likely a
> universally correct setting, the creation mode needs to be configurable.

It doesn't appear to me that this helps unless you are willing to make
the containing director(ies) group-readable/executable as well, which is
something we've resisted doing.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> writes:
>> It'd be convenient if the log files would have group read access.
>> Then we could make all the DBA or monitoring users members of the
>> postgres group and they'd have direct access to the logs.
>> However, as the "group read" is not likely a universally correct
>> setting, the creation mode needs to be configurable.
>
> It doesn't appear to me that this helps unless you are willing to
> make the containing director(ies) group-readable/executable as
> well, which is something we've resisted doing.

I just tried creating a symbolic link to the pg_log directory and
flagging the existing logs within it to 640. As a member of the
group I was able to list and view the contents of log files through
the symbolic link, even though I didn't have any authority to the
PostgreSQL data directory.

That seems potentially useful to me.

-Kevin

Tom Lane wrote:
> It doesn't appear to me that this helps unless you are willing to make
> the containing director(ies) group-readable/executable as well, which is
> something we've resisted doing.
>

The log can be moved outside of data directory by setting "log_directory"
to an absolute path. Then the permissions for the log directory can be arbitrary
as the postmaster is only strict about permissions on data directory.

regards,
Martin

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> writes:
> > It'd be convenient if the log files would have group read access. Then we could
> > make all the DBA or monitoring users members of the postgres group and they'd
> > have direct access to the logs. However, as the "group read" is not likely a
> > universally correct setting, the creation mode needs to be configurable.
>
> It doesn't appear to me that this helps unless you are willing to make
> the containing director(ies) group-readable/executable as well, which is
> something we've resisted doing.

Perhaps we should have a umask-like GUC instead of this?

In the end, I agree with and completely understand the OP's complaint.
I havn't run into this issue much since, on Debian systems, we use
logrotate to move log files around and use the copy/truncate method
there, so permissions end up being preserved once an admin has decided
to change them. Might be something to consider, but, really, we should
give the admin some flexibility here, even if the default is the same as
current behaviour.

I'll refrain from bringing up the fact that we're concerned about log
files having group permissions by default, but we ship with "trust" in
pg_hba.conf...

Thanks,

Stephen

Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> writes:
> Tom Lane wrote:
>> It doesn't appear to me that this helps unless you are willing to make
>> the containing director(ies) group-readable/executable as well, which is
>> something we've resisted doing.

> The log can be moved outside of data directory by setting "log_directory"
> to an absolute path.

Oh, of course. We'd need to mention that in the documentation for the
log-file-permission GUC.

regards, tom lane

On 07/01/2010 12:56 PM, Kevin Grittner wrote:
> I just tried creating a symbolic link to the pg_log directory and
> flagging the existing logs within it to 640. As a member of the
> group I was able to list and view the contents of log files through
> the symbolic link, even though I didn't have any authority to the
> PostgreSQL data directory.
>
> That seems potentially useful to me.

Symlinks are exactly equivalent to using the target of the link. Your
permissions are probably already arranged so that you (as a group
member) can access the files. Fedora's initscript seems to deliberately
revoke group permissions from PGDATA and pg_log so I'm guessing that at
some point some things were created with some group permissions.

That said, as Martin mentions one can easily place the log directory
outside of the data directory and set appropriate directory permissions.

-- m. tharp

On Thu, Jul 1, 2010 at 12:19 PM, Michael Tharp
<gxti(at)partiallystapled(dot)com> wrote:
> That said, as Martin mentions one can easily place the log directory outside
> of the data directory and set appropriate directory permissions.

If I can offer my $0.02, I recently solved such a problem on SuSE
Linux with apache logs. I used the ACL support on ext3 to give a
specific group read-only access:

cd /var/log
# Add an ACL for the 'www' user
setfacl -m u:www:r-x apache2
setfacl -m u:www:r-- apache2/*
# Modify the default ACL so that new files get 'r' for user
setfacl -d -m u:www:r-- apache2

Just pointing out that this problem is solvable on systems that
support ACLs w/o patching postgres.

Martin Pihlak wrote:
> Attached is a patch that adds a GUC "log_file_mode" which allows to specify
> the creation mode for the log files. Presently it lacks documentation, which
> I'll add if the idea is generally acceptable.
>

Updated patch attached.

regards,
Martin