Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id RAA45782
	for <pgsql-interfaces@postgreSQL.org>;
	Sat, 20 Nov 1999 17:59:46 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA28769;
	Sat, 20 Nov 1999 17:57:58 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: "Sergio A. Kessler" <ser@perio.unlp.edu.ar>,
	"pgsql-interfaces@postgreSQL.org" <pgsql-interfaces@postgreSQL.org>
Subject: Re: [INTERFACES] pg_pwd 
In-reply-to: Your message of Sat, 20 Nov 1999 17:41:34 -0500
	<99112017500100.00543@lorc.wgcr.org>
Date: Sat, 20 Nov 1999 17:57:58 -0500
Message-ID: <28767.943138678@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:
> And yes, this IS a glaring security hole, IF the user postgres has a postgres
> password.  Just WHY is pg_pwd mode 666 in the first place??

Because it's written out with a backend-side COPY operation, and
backend-side COPY makes *every* file it creates mode 666.

As I commented earlier in this thread, I think COPY ought not create
files with looser permissions than 644 (does anyone know why that's
not true already?).  But that still wouldn't be good enough for pg_pwd.

Maybe it would be worthwhile to try to force pg_pwd in particular
to be written with just mode 600.  In the standard configuration that
shouldn't make any difference ... but if people are going to use
hacked-up initdb code, as you evidently are doing, we probably should
not rely on the data directory to be locked up tightly...

			regards, tom lane