The following bug has been logged online:

Bug reference: 2088
Logged by: Dick Snippe
Email address: Dick.Snippe (AT) tech (DOT) omroep.nl
PostgreSQL version: 8.1.0
Operating system: Fedora Core 2
Description: logfiles only readable by instance owner
Details:

when redirect_stderr = true
the logfiles created by log_filename are only readable by the postgres
instance owner.
I assume this is caused by umask((mode_t) 0077) on line 414 in
scr/backend/postmaster/postmaster.c

setting umask 077 makes sense for the data files, but not per se for the
logfile.
It would be nice if the logfile mode was configurable, or defaulted to 644
or 640.
A similar scheme to setting the permissions on unix_socket_directory could
perhaps be used.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Dick Snippe" <Dick.Snippe (AT) tech (DOT) omroep.nl> writes:
The logfile typically contains data just as sensitive as the data files,
so I disagree.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Fri, Dec 02, 2005 at 12:30:17AM -0500, Tom Lane wrote:

true.

we run postgresql as a database engine behind a number of websites.
Typically all the data in the database is public data . It would be very
nice if there was a method of letting our developers _read_ the logfile,
without giving them _write_ access to the data files.

What wrong with making this configurable?

--
Dick Snippe - een Coordinator Publieke Omroep Internet Services
Gebouw 12.401 (peperbus) Sumatralaan 45 Hilversum \ fight war
tel +31 35 6774252, email beheer (AT) omroep (DOT) nl []() \ not wars

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Dick Snippe wrote:
We can't add every features that people ask for or our software would be
unusable. If your log files recycle at midnight, can't you run a cron
job to chmod it? I suppose if you can find other users who would like
to set the mode flags on the file, we can add it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Fri, Dec 02, 2005 at 12:59:17PM -0500, Bruce Momjian wrote:
Would it be possible to rely on setting umask in the shell instead of
hardcoding 077? I guess that would end up being dependant on different
startup scripts though, so it's probably not a good idea.

An alternative is to just use syslog. Or I believe you could use a
log-rotation program that allows you to define permissions and tell
PostgreSQL not to rotate.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby (AT) pervasive (DOT) com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Fri, Dec 02, 2005 at 02:11:06PM -0600, Jim C. Nasby wrote:

*mumble* mysql *mumble* $UMASK *mumble* $UMASK_DIR *nuff said* :-)

I used to use syslog, but prefer direct file logging, because it keeps the
logfiles closer to the application (e.g. useful when running more than 1
instance on the same host)

Using a log rotation program is possible (apache rotatelogs comes to mind),
but that would require starting postgresql with something like
postmaster | rotatelogs
and just hope that rotetelogs doesn't die in the weeks or months that
postmaster runs. Also postmaster can't be started as a daemon in this case.

The other log rotation option (typically logrotate; e.g. let postgresql
log to file and periodically rotate that file by using an external
script) may not be an option, because I'm not sure that postgresql
closes and reopens its logfiles when it receives a sighup.

I think I'll stick to touching the logfiles 5 minutes before postmaster
may decide to create them.

--
Dick Snippe - een Coordinator Publieke Omroep Internet Services
Gebouw 12.401 (peperbus) Sumatralaan 45 Hilversum \ fight war
tel +31 35 6774252, email beheer (AT) omroep (DOT) nl []() \ not wars

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Fri, Dec 02, 2005 at 12:59:17PM -0500, Bruce Momjian wrote:

granted. But hardcoding it is the other extreme.

good idea. Actually, I think touching the file before postgresql creates it
might even be better (because when postgres has nothing to log there may not
be a logfile to chmod), something along the lines of
55 23 * * * touch $(date --date=tomorrow '+logfile-%Y-%m-%d')

Who knows. Keep in mind that logging to file is a relatively new feature in
postgresql. We used to log to syslog, but switched to file logging because
of the nice logfile rotation features available in 8.x
So, when more people switch from 7.x to 8.x, this feature request might pop
up more often.

--
Dick Snippe - een Coordinator Publieke Omroep Internet Services
Gebouw 12.401 (peperbus) Sumatralaan 45 Hilversum \ fight war
tel +31 35 6774252, email beheer (AT) omroep (DOT) nl []() \ not wars

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Fri, Dec 02, 2005 at 23:30:21 +0100,
Dick Snippe <Dick.Snippe (AT) tech (DOT) omroep.nl> wrote:
You can use multilog in DJB's daemontools package to do this.

It writes the logfiles publicly readable, so you control access to them via
the directory they are contained in.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match