Re: Minimising windows installer password confusion

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Sachin Srivastava <sachin(dot)srivastava(at)enterprisedb(dot)com>, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>, Dharmendra Goyal <dharmendra(dot)goyal(at)enterprisedb(dot)com>
Subject: Re: Minimising windows installer password confusion
Date: 2012-06-13 23:55:50
Message-ID: 4FD92886.8040008@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/13/2012 05:14 PM, Dave Page wrote:
> On Wed, Jun 13, 2012 at 2:18 AM, Craig Ringer
> <craig(at)postnewspapers(dot)com(dot)au> wrote:
>> On 06/12/2012 08:08 PM, Dave Page wrote:
>>> Some background: By default the installer will use 'postgres' for both
>>> the service (OS) account, and the database superuser account. It will
>>> use the same password for both (though, users have complete control at
>>> the command line if they want it, which is why the account names are
>>> shown in the installer). Unlike *nix installations, the service
>>> account must have a password, which is required during both
>>> installation and upgrade to configure the PostgreSQL service. We
>>> therefore ask for the password during both installation and upgrade.
>>> If the user account exists (which can happen if there has previously
>>> been an installation of Postgres on the system), the user must specify
>>> the existing password for the account during installation (and of
>>> course, during all upgrades). This is where users normally get stuck,
>>> as they've forgotten the password they set in the past.
>> They may not even have set it, because the EnterpriseDB installer can be run
>> unattended and may've been used by some 3rd party package.
>>
>> I'd be interested in seeing what Microsoft installers that create isolated
>> user accounts do. I think .NET creates one for ASP, so that'd be one option
>> to look into.
> They tend to use the localsystem or networkservice accounts for most
> things, which don't have passwords. The reason we don't do that is
> that since the early days of 8.0 we've said we want to enable users to
> use the service account as if it were a regular account, so that they
> can do things like access network resources (useful for server-side
> copy for example).
>
> I wasn't overly convinced back then that that was necessary, and I'm
> still not now. I suppose we potentially could use the networkservice
> account by default, and let advanced users override that on the
> command line if they need to. Then remembering the password becomes
> their responsibility.
+1 from me on this, though I think making the service account part of
the install process makes sense.

SERVICE ACCOUNT
-------------------------

You can probably just accept the default here.

PostgreSQL runs in the background as a network service in a user account
that
only has limited access to the files and programs on the computer. This
is fine
for most purposes, but will prevent certain operations like server-side
COPY and
direct access by the server to resources on shared folders from working.
If you
need these capabilities, we recommend that you create a "postgres" user
account
below and have the PostgreSQL server run in that instead of the default
NetworkService account.

-- [service account] -----------------------
| |
| [*] LocalService |
| |
| [ ] Custom Service Account |
| |
| -- [custom account]------------------| |
| | | |
| | Username: [ ] | |
| | Password: [ ] | |
| | Domain: [ THISCOMPUTER ] | |
| | | |
| |------------------------------------| |
|------------------------------------------|

Reasonable option?

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-06-14 00:22:00 Re: Ability to listen on two unix sockets
Previous Message Tom Lane 2012-06-13 23:49:07 Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.