Thread: pg_pwd

I committed a few changes to the user creation code which should, in
theory, make them more robust (doesn't use pg_exec_query_dest anymore).
Due to an inherent design conflict the update of the password file cannot
use the COPY logic anymore (the copy command wouldn't see the last changed
tuple), so it does it itself now, which looks better to me anyway. The
format of the file is still the same, I just filled up the unused spots
with x's and 0's. The remaining problem is initdb, which writes the
initial pg_pwd with COPY, so we can't go to a different, more compact
format yet. A solution for this would be to scrap this call and instead
call

echo "ALTER USER $POSTGRES WITH PASSWORD '$WHATEVER'" | postgres ...

in initdb and forget about all the scary sed -f or similar things that
have been proposed recently to get the password in there securely. That
way we can be assured to have the password file always in the format it
will be later on.

Bruce, are you still working on that part?

A few other side effects of the changes were:

* Even unprivileged users can change their own password (but nothing else)

* The password is now an Sconst in the parser, which better reflects its
text datatype and also forces users to quote them.

* If your password is NULL you won't be written to the password file,
meaning you can't connect until you have a password set up (if you use
password authentication).

* When you drop a user that owns a database you get an error. The database
is not gone.

These are minor "wholesale" changes, but I thought they would be in the
public's interest.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> I committed a few changes to the user creation code which should, in
> theory, make them more robust (doesn't use pg_exec_query_dest anymore).

Great.  I have been hoping for this.

> Due to an inherent design conflict the update of the password file cannot
> use the COPY logic anymore (the copy command wouldn't see the last changed
> tuple), so it does it itself now, which looks better to me anyway. The
> format of the file is still the same, I just filled up the unused spots
> with x's and 0's. The remaining problem is initdb, which writes the
> initial pg_pwd with COPY, so we can't go to a different, more compact
> format yet. A solution for this would be to scrap this call and instead
> call
> 
> echo "ALTER USER $POSTGRES WITH PASSWORD '$WHATEVER'" | postgres ...

That is fine with me.

> in initdb and forget about all the scary sed -f or similar things that
> have been proposed recently to get the password in there securely. That
> way we can be assured to have the password file always in the format it
> will be later on.
> 
> Bruce, are you still working on that part?

Sure, the echo is fine.  If not, you do whatever you want, and I will go
in and make it secure.

> 
> A few other side effects of the changes were:
> 
> * Even unprivileged users can change their own password (but nothing else)

Great.

> 
> * The password is now an Sconst in the parser, which better reflects its
> text datatype and also forces users to quote them.
> 
> * If your password is NULL you won't be written to the password file,
> meaning you can't connect until you have a password set up (if you use
> password authentication).
> 
> * When you drop a user that owns a database you get an error. The database
> is not gone.
> 
> These are minor "wholesale" changes, but I thought they would be in the
> public's interest.

Sounds like a nice set of patches.  We need to get Peter on the
Developers page.  Vince?

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026