Re: Minimising windows installer password confusion - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Minimising windows installer password confusion
Date
Msg-id 4FD92886.8040008@postnewspapers.com.au
Whole thread Raw
In response to Re: Minimising windows installer password confusion  (Dave Page <dpage@pgadmin.org>)
Responses Re: Minimising windows installer password confusion
List pgsql-hackers
On 06/13/2012 05:14 PM, Dave Page wrote:
> On Wed, Jun 13, 2012 at 2:18 AM, Craig Ringer
> <craig@postnewspapers.com.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/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
Next
From: Bruce Momjian
Date:
Subject: Re: Ability to listen on two unix sockets