Re: BUG #5475: Problem during Instalation

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Joel Henrique <joel(at)cefet-al(dot)br>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5475: Problem during Instalation
Date: 2010-06-09 07:56:23
Message-ID: 4C0F4927.7070507@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 09/06/10 15:47, Dave Page wrote:
> On Wed, Jun 9, 2010 at 4:58 AM, Craig Ringer
> <craig(at)postnewspapers(dot)com(dot)au> wrote:
>
>> Really, the installer on Windows needs to stash the password in an
>> admin-only-readable registry key, read it from there on install, and test to
>> make sure it works. If it does, Pg need not even bother the user with the
>> account password at all.
>
> Aside from the fact that such a technique would probably end up on
> Bugtraq quicker than I could write the report myself, many people do
> need the password for setting up additional services such as pgAgent,
> and for actually logging into the database they just installed.

Only because the PostgreSQL system user account password is coupled to
the account of the "postgres" user in the PostgreSQL database cluster
(right?). I'm not at a Windows box right now so I can't test to see if
altering the Pg role's password changes the system password or vice
versa, but I'd be surprised if they did.

Personally I'm firmly of the opinion that the user should never need to
know anything about the password (if any) for the "postgres" Windows
user account that's used for the service account.

As for bugtraq: If the password is in a registry key readable only by
the administrator user, then anyone who can read the password can also
change the password for the account, read other critical passwords from
the system, etc. Admittedly it'd be stored in cleartext, but so are
plenty of stored passwords. Now, if that password is the same as the one
used for the db admin user, then yes that'd be an absolutely awful idea,
but I was presuming that as it'd be a behind-the-scenes generated
password it'd be completely independent from the "postgres" role in the
db cluster if this method was used.

It'd be even better, of course, to find out how others avoid this whole
issue and do the same. I'm going to do some digging and see if I can
find that out, so I can give you some useful information instead of
hand-waving.

--
Craig Ringer

Tech-related writing: http://soapyfrogs.blogspot.com/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Martin Edlman 2010-06-09 08:01:48 BUG #5495: RI/FK on self and inherited table
Previous Message Dean Rasheed 2010-06-09 07:51:41 Re: Invalid YAML output from EXPLAIN