On Fri, Mar 09, 2012 at 11:33:36AM -0500, Bruce Momjian wrote:
> On Fri, Mar 09, 2012 at 10:41:53AM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > The problem is that these files are being created often by shell
> > > redirects, e.g. pg_dump -f out 2> log_file. There is no clean way to
>
On Fri, Mar 09, 2012 at 10:41:53AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > The problem is that these files are being created often by shell
> > redirects, e.g. pg_dump -f out 2> log_file. There is no clean way to
> > control the file creation permissions in this case --- only umask giv
Bruce Momjian writes:
> The problem is that these files are being created often by shell
> redirects, e.g. pg_dump -f out 2> log_file. There is no clean way to
> control the file creation permissions in this case --- only umask gives
> us a process-level setting. Actually, one crafty idea would
On Fri, Mar 09, 2012 at 10:18:31AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > What do people think of pg_upgrade setting its umask to 0077 so the log
> > and SQL files are only readable by the postgres user?
>
> +1 for restricting the log files, but I'm dubious that you should alter
> the
On fre, 2012-03-09 at 10:10 -0500, Bruce Momjian wrote:
> What do people think of pg_upgrade setting its umask to 0077 so the
> log and SQL files are only readable by the postgres user?
That would be good to have.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Bruce Momjian writes:
> What do people think of pg_upgrade setting its umask to 0077 so the log
> and SQL files are only readable by the postgres user?
+1 for restricting the log files, but I'm dubious that you should alter
the existing permissions on copied files in any way.
IOW, umask seems li
