| 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: | Whole Thread | Raw Message | 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 |