Thread: BUG #2088: logfiles only readable by instance owner
The following bug has been logged online: Bug reference: 2088 Logged by: Dick Snippe Email address: Dick.Snippe@tech.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.
"Dick Snippe" <Dick.Snippe@tech.omroep.nl> writes:
> setting umask 077 makes sense for the data files, but not per se for the
> logfile.
The logfile typically contains data just as sensitive as the data files,
so I disagree.
regards, tom lane
On Fri, Dec 02, 2005 at 12:30:17AM -0500, Tom Lane wrote: > "Dick Snippe" <Dick.Snippe@tech.omroep.nl> writes: > > setting umask 077 makes sense for the data files, but not per se for the > > logfile. > > The logfile typically contains data just as sensitive as the data files, true. > so I disagree. 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@omroep.nl []() \ not wars
Dick Snippe wrote: > On Fri, Dec 02, 2005 at 12:30:17AM -0500, Tom Lane wrote: > > > "Dick Snippe" <Dick.Snippe@tech.omroep.nl> writes: > > > setting umask 077 makes sense for the data files, but not per se for the > > > logfile. > > > > The logfile typically contains data just as sensitive as the data files, > > true. > > > so I disagree. > > 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? 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@candle.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
On Fri, Dec 02, 2005 at 12:59:17PM -0500, Bruce Momjian wrote: > Dick Snippe wrote: > > On Fri, Dec 02, 2005 at 12:30:17AM -0500, Tom Lane wrote: > > > > > "Dick Snippe" <Dick.Snippe@tech.omroep.nl> writes: > > > > setting umask 077 makes sense for the data files, but not per se for the > > > > logfile. > > > > > > The logfile typically contains data just as sensitive as the data files, > > > > true. > > > > > so I disagree. > > > > 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? > > 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. 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@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Fri, Dec 02, 2005 at 02:11:06PM -0600, Jim C. Nasby wrote:
> On Fri, Dec 02, 2005 at 12:59:17PM -0500, Bruce Momjian wrote:
> > Dick Snippe wrote:
> > > On Fri, Dec 02, 2005 at 12:30:17AM -0500, Tom Lane wrote:
> > >
> > > > "Dick Snippe" <Dick.Snippe@tech.omroep.nl> writes:
> > > > > setting umask 077 makes sense for the data files, but not per se for the
> > > > > logfile.
> > > >
> > > > The logfile typically contains data just as sensitive as the data files,
> > >
> > > true.
> > >
> > > > so I disagree.
> > >
> > > 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?
> >
> > 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.
>
> 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.
*mumble* mysql *mumble* $UMASK *mumble* $UMASK_DIR *nuff said* :-)
> 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.
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@omroep.nl []() \ not wars
On Fri, Dec 02, 2005 at 12:59:17PM -0500, Bruce Momjian wrote: > Dick Snippe wrote: > > On Fri, Dec 02, 2005 at 12:30:17AM -0500, Tom Lane wrote: > > > > > "Dick Snippe" <Dick.Snippe@tech.omroep.nl> writes: > > > > setting umask 077 makes sense for the data files, but not per se for the > > > > logfile. > > > > > > The logfile typically contains data just as sensitive as the data files, > > > > true. > > > > > so I disagree. > > > > 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? > > We can't add every features that people ask for or our software would be > unusable. granted. But hardcoding it is the other extreme. > If your log files recycle at midnight, can't you run a cron > job to chmod it? 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') > I suppose if you can find other users who would like > to set the mode flags on the file, we can add it. 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@omroep.nl []() \ not wars
On Fri, Dec 02, 2005 at 23:30:21 +0100, Dick Snippe <Dick.Snippe@tech.omroep.nl> wrote: > > 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. 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.