[Fwd: Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)]

Message-ID: <34EC9DF0.7F61@mpdft.gov.br>
Date: Thu, 19 Feb 1998 18:02:40 -0300
From: Robson Paniago de Miranda <robson@mpdft.gov.br>
Reply-To: robson@mpdft.gov.br
Organization: MPDFT
X-Mailer: Mozilla 3.0 (WinNT; I)
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
References: <199802191946.OAA11923@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

On Thu, 19 Feb 1998, Bruce Momjian wrote:

On Thu, 19 Feb 1998, Bruce Momjian wrote:

Just curious, but why don't the copy command fall under the same
grant/revoke restrictions in the first place? It sounds to me like we are
backing off of the problem instead of addressing it...

grant/revoke works for copy.

Ah, okay, so when we have it setup so that a view overrides the
'grant' of a select, then we're fine?

Yep, but can we do that in nine days, and be sure it is tested?

I don't think so...but I'rather have the obviuos "select * from
pg_user" closed off, and the more obscure "copy pg_user to stdout" still
there then have both wide open...its a half measure, but its better then
no measure...

But it is not secure. Why have passwords then?

I think is better have the encrypted passwords and the salt in pg_user.
I don't know if this will be bing a security hole :(

Robson.