> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: 04 May 2004 16:08
> To: Magnus Hagander
> Cc: Tom Lane; Andrew Dunstan; [EMAIL PROTECTED]
> Subject: Re: [PATCHES] Run-as-admin warning for win32
> 
> 
> Magnus Hagander wrote:
> > > > The installer-skeleton I have right now permits
> > > installation as local
> > > > system but recommends a user account. But that's just
> > > functionality to
> > > > remove, so that's easily done. In the other case, it prompts for
> > > > username and password to run as.
> > > 
> > > How would it install on an XP laptop?  If I am logged in as
> > > myself and I am listed as a "Computer Administrator", do I 
> > > need to create another user, and how do I do the install as 
> > > that other user, and start/stop the server, and stuff like that?
> > 
> > Yes, you need to create another user.
> > When running as a service, just tell the installer. It 
> should set up 
> > required permissions. Then start the service as normal using the 
> > Service Control Manager.
> > 
> > When running manually, you will have to grant the postgres user the 
> > required permissions on the PGDATA directory. Then you can 
> start the 
> > server using "runas".
> 
> Ewe, big on security, small on ease-of-use.  :-)
> 
> I have never had to create a user to install any other 
> software on my laptop.


Just listening in on this thread.... I would be inclined to agree that
the Win32 PostgeSQL should run under its own user given the history of
Windows security. FWIW I know that Installshield (one of the most
popular installers) and the default settings for MSI mean that only
administrators can install software; so I would argue that there is no
reason why the PostgreSQL installer also shouldn't require administrator
privilege to run, and therefore create the postgres user account for us.

I think that most of the services installed under Win32 use a separate
username and password. The last installer I used that required a
username and password was for a backup service and then it was simply a
page in the installer that asked for a username and password to run
under; both of these were set to defaults so all I had to do was click
"Next" and the account was generated for me and the directory
permissions set up correctly. This has the balance that the novice user
will just click "Next" while the advanced user can set up a customised
account to meet his/her needs.

In the case of a stand-alone executable, I can see things being a little
more tricky; however I don't see there being any reason why when we
launch the backend we try the default username and password (postgres
and "") and if that doesn't work then we ask for a new username and
password from the user. I would see that this wouldn't be done in the
backend but in the equivalent of the /etc/init.d/postgresql script under
Win32. If people really got upset about asking for the account password
on startup then I guess they would have to go for the service
installation - I see this as being no different to the inconvenience of
asking for a PEM passphrase when we restart Apache on our Linux servers.

Finally I believe we can tighten up security from SMB/RPC-based exploits
by applying the "can only logon locally" policy to the postgres account
which means that SMB/RPC connections cannot be made with the default
PostgreSQL username and password which is always a good thing :)


Kind regards,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to