56 lines
2.9 KiB
Plaintext
56 lines
2.9 KiB
Plaintext
From owner-pgsql-hackers@hub.org Sun Aug 2 20:01:13 1998
|
|
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
|
|
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id UAA15937
|
|
for <maillist@candle.pha.pa.us>; Sun, 2 Aug 1998 20:01:11 -0400 (EDT)
|
|
Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id TAA01026 for <maillist@candle.pha.pa.us>; Sun, 2 Aug 1998 19:33:53 -0400 (EDT)
|
|
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id TAA19878; Sun, 2 Aug 1998 19:30:59 -0400 (EDT)
|
|
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 02 Aug 1998 19:28:23 +0000 (EDT)
|
|
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id TAA19534 for pgsql-hackers-outgoing; Sun, 2 Aug 1998 19:28:22 -0400 (EDT)
|
|
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id TAA19521 for <pgsql-hackers@postgreSQL.org>; Sun, 2 Aug 1998 19:28:15 -0400 (EDT)
|
|
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 TAA22594
|
|
for <pgsql-hackers@postgreSQL.org>; Sun, 2 Aug 1998 19:28:13 -0400 (EDT)
|
|
To: pgsql-hackers@postgreSQL.org
|
|
Subject: [HACKERS] TODO item: make pg_shadow updates more robust
|
|
Date: Sun, 02 Aug 1998 19:28:13 -0400
|
|
Message-ID: <22591.902100493@sss.pgh.pa.us>
|
|
From: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Sender: owner-pgsql-hackers@hub.org
|
|
Precedence: bulk
|
|
Status: ROr
|
|
|
|
I learned the hard way last night that the postmaster's password
|
|
authentication routines don't look at the pg_shadow table. They
|
|
look at a separate file named pg_pwd, which certain backend operations
|
|
will update from pg_shadow. (This is not documented in any user
|
|
documentation that I could find; I had to burrow into
|
|
src/backend/commands/user.c to discover it.)
|
|
|
|
Unfortunately, if a clueless dbadmin (like me ;-)) tries to update
|
|
password data with the obvious thing,
|
|
update pg_shadow set passwd = 'xxxxx' where usename = 'yyyy';
|
|
pg_pwd doesn't get fixed.
|
|
|
|
A more drastic problem is that pg_dump believes it can save and
|
|
restore pg_shadow data using "copy". Following an initdb and restore
|
|
from a pg_dump -z script, pg_shadow will look just fine, but only
|
|
the database admin will be listed in pg_pwd. This is likely to provoke
|
|
some confusion, IMHO.
|
|
|
|
As a short-term thing, the fact that you *must* set passwords with
|
|
ALTER USER ought to be documented, preferably someplace where a
|
|
dbadmin who's never heard of ALTER USER is likely to find it.
|
|
|
|
As a longer-term thing, I think it would be far better if ordinary
|
|
SQL operations on pg_shadow just did the right thing. Wouldn't it
|
|
be possible to implement copying to pg_pwd by means of a trigger on
|
|
pg_shadow updates, or something like that?
|
|
|
|
(I'm afraid that pg_dump -z is pretty well broken for operations on
|
|
a password-protected database, btw. Has anyone used it successfully
|
|
in that situation?)
|
|
|
|
regards, tom lane
|
|
|
|
|