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 <br...@momjian.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. > > Yes, that is what I have done, with the attached patch. I basically > wrapped the fopen call with umask calls, and have the system() call > wrapped too. That takes care of all the files pg_upgrade creates. > > > > 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. > > Yes, that was my conclusion too, but I wanted to ask. FYI, this doesn't > affect the install itself, just what pg_upgrade changes, and it doesn't > touch postgresql.conf, but, as you, I am worried there might be > long-term problems with an aggressive umask that covered the entire > executable.
I ended up creating fopen_priv to centralize the umask calls to a single function, and added an is_priv boolean to exec_prog for the same purpose. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers