From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade and umask |
Date: | 2012-03-09 15:41:53 |
Message-ID: | 29743.1331307713@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> 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 be to do
> the umask only when I exec something, and when I create the initial
> files with the new banner you suggested. Let me look into that.
You could create empty log files with the desired permissions, and then
do the execs with >>log_file, and thereby not have to globally change
umask.
> Frankly, the permissions are already being modified by the default
> umask, e.g. 0022. Do we want a zero umask?
I'm not so worried about default umask; nobody's complained yet about
wrong permissions on pg_upgrade output files. But umask 077 would be
likely to do things like get rid of group access to postgresql.conf,
which some people intentionally set.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-03-09 15:50:05 | Re: pg_prewarm |
Previous Message | Tom Lane | 2012-03-09 15:37:42 | Re: xlog location arithmetic |