Обсуждение: BUG #5475: Problem during Instalation
The following bug has been logged online: Bug reference: 5475 Logged by: Joel Henrique Email address: joel@cefet-al.br PostgreSQL version: 8.4.4-1 Operating system: Windows 2003 Server Description: Problem during Instalation Details: When I try to install postgres it asks for a password. It says that if the service already exists I should put the current password, otherwise a service will be created with new password. I've neves installed postgres before. What kind of password is that? I can't install postgres here. Thanks!
On Wed, May 26, 2010 at 9:48 AM, Joel Henrique <joel@cefet-al.br> wrote: > > The following bug has been logged online: > > Bug reference: =A0 =A0 =A05475 > Logged by: =A0 =A0 =A0 =A0 =A0Joel Henrique > Email address: =A0 =A0 =A0joel@cefet-al.br > PostgreSQL version: 8.4.4-1 > Operating system: =A0 Windows 2003 Server > Description: =A0 =A0 =A0 =A0Problem during Instalation > Details: > > When I try to install postgres it asks for a password. > It says that if the service already exists I should put the current > password, otherwise a service will be created with new password. > > I've neves installed postgres before. What kind of password is that? I ca= n't > install postgres here. I feel like we've had this question a few times before, and answered it, but I'm not a Windows guy and can't remember the answer. Can we add an FAQ entry for this, or something? --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On 9/06/2010 11:06 AM, Robert Haas wrote: > On Wed, May 26, 2010 at 9:48 AM, Joel Henrique<joel@cefet-al.br> wrote: >> >> The following bug has been logged online: >> >> Bug reference: 5475 >> Logged by: Joel Henrique >> Email address: joel@cefet-al.br >> PostgreSQL version: 8.4.4-1 >> Operating system: Windows 2003 Server >> Description: Problem during Instalation >> Details: >> >> When I try to install postgres it asks for a password. >> It says that if the service already exists I should put the current >> password, otherwise a service will be created with new password. >> >> I've neves installed postgres before. What kind of password is that? I can't >> install postgres here. > > I feel like we've had this question a few times before, and answered > it, but I'm not a Windows guy and can't remember the answer. Can we > add an FAQ entry for this, or something? 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. It'd be worth looking at how (eg) ASP.NET and IIS handle their account passwords. They don't seem to have these issues. Perhaps a FAQ entry would be a good idea in the mean time, though. Let me see if I can put something together. -- Craig Ringer
On 5/26/10 7:18 PM, Joel Henrique wrote: > The following bug has been logged online: > > Bug reference: 5475 > Logged by: Joel Henrique > Email address: joel@cefet-al.br > PostgreSQL version: 8.4.4-1 > Operating system: Windows 2003 Server > Description: Problem during Instalation > Details: > > When I try to install postgres it asks for a password. > It says that if the service already exists I should put the current > password, otherwise a service will be created with new password. > > I've neves installed postgres before. What kind of password is that? I can't > install postgres here. > Since you dont have a 'postgres' user, Just give any password and the a new user 'postgres' will be created with the supplied password which then will be used as the service account owner of PostgreSQL service. In case you have a postgres user pre-existing on your system, supply its password when asked by the installer. You can anytime change the password by going to administartive tasks--> Users and groups .. > Thanks! > > -- Regards, Sachin Srivastava EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres <http://www.enterprisedb.com> company.
On Wed, Jun 9, 2010 at 4:58 AM, Craig Ringer <craig@postnewspapers.com.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. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On 09/06/10 15:47, Dave Page wrote: > On Wed, Jun 9, 2010 at 4:58 AM, Craig Ringer > <craig@postnewspapers.com.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/
On Wed, Jun 9, 2010 at 8:56 AM, Craig Ringer <craig@postnewspapers.com.au> wrote: > 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. It won't, but the point is that we have to ask for a password anyway so we don't gain anything by not asking the user for one of them. > 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. So how would you install something like pgAgent, which you would most likely want to run under the same 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. You can have multiple administrators on a machine, and storage of a plain text password in the registry would allow knowledge of that password to leak from one administrator to another, which may cause security concerns in a tightly controlled environment. As far as I'm aware, Windows doesn't provide any way for an Administrator to read any other local/domain passwords in anything other than an encrypted/hashed form, so this would be a new issue, not normally seen. > 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. Most other services use one of the 'special' accounts like 'Network Service', however doing that with Postgres doesn't necessarily play well with features like COPY, which is why we've avoiding doing that since 8.0. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On 09/06/10 16:29, Dave Page wrote: > On Wed, Jun 9, 2010 at 8:56 AM, Craig Ringer > <craig@postnewspapers.com.au> wrote: > >> 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. > > It won't, but the point is that we have to ask for a password anyway > so we don't gain anything by not asking the user for one of them. The issue is that the user has to know if they've installed Pg before (and thus already have a "postgres" service account) or not. Some clearly don't, or have forgotten the service account password long ago. In general, users expect that an uninstall of an app will remove the app's configuration. Pg ... sort of ... does. It leaves the user account in place, though it created it in the first place. So the user has to know if Pg has been installed previously and if so what the service account password was. This demonstrably confuses people who try to uninstall and reinstall Pg to resolve issues (service account configuration related or other). As you've pointed out good reasons why just storing a generated password may not be a good idea, let me propose another approach that might help users with what's clearly a confusing point for many: - During the install, test for the existence of a 'postgres' user account before displaying the password prompt panel of the installer "wizard". - If such an account does not exist, display the existing UI password prompt ui with simplified language indicating that you're creating a new password not entering one already set. People seem to struggle with this at present. - If such an account already exists, tell the user that PostgreSQL has been installed in the past or another version is currently installed, so they must provide the password that was supplied during that prior installation. If they do not know the password, they may press an offered "reset password" button to enter a new one, but they're warned that doing so will cause any other versions of PostgreSQL to stop working. ------ or possibly ..... -------- - When the postgres user password is reset on the PostgreSQL service via the Pg installer, update or offer to update *all* service registrations for any service using the postgres account so that they use the same password, thus avoiding breaking old versions when the user has forgotten the service account password. >> 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. > > So how would you install something like pgAgent, which you would most > likely want to run under the same account? Installers run as admin; it'd read the registry key during installation and use it for the CreateService call. > You can have multiple administrators on a machine, and storage of a > plain text password in the registry would allow knowledge of that > password to leak from one administrator to another, which may cause > security concerns in a tightly controlled environment. As far as I'm > aware, Windows doesn't provide any way for an Administrator to read > any other local/domain passwords in anything other than an > encrypted/hashed form, so this would be a new issue, not normally > seen. True, and a good point, particularly on domain setups. OTOH, if it's a generated password, leaking it has little effect as it's unique to the machine and only grants access to a service account that the admin user already has access to by virtue of their admin status on that machine. It's not re-used anywhere and if you can read it you can change it or become that user. Nonetheless, I'll grant that I understand and agree with your caution about that notion. I don't like it much either, I just don't like the way things work right now any more, as the questions and posts here suggest that it causes plenty of confusion for users. > Most other services use one of the 'special' accounts like 'Network > Service', however doing that with Postgres doesn't necessarily play > well with features like COPY, which is why we've avoiding doing that > since 8.0. That much makes perfect sense and I certainly wasn't arguing that it should live in the generic service account. There are clear and good reasons to run Pg in its own service account, well beyond merely separating it from other services. A bit of digging reveals that most decent services are using local or domain accounts, with passwords, and are just living with the administrator hassle this creates, expecting admins to be competent enough to change and maintain service passwords. I'm not sure Pg can rely on that for desktop installs, though, so it might need to offer a way to take service account password management into its own hands. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/
On 6/9/10 2:33 PM, Craig Ringer wrote: > On 09/06/10 16:29, Dave Page wrote: > >> On Wed, Jun 9, 2010 at 8:56 AM, Craig Ringer >> <craig@postnewspapers.com.au> wrote: >> >> >>> 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. >>> >> It won't, but the point is that we have to ask for a password anyway >> so we don't gain anything by not asking the user for one of them. >> > The issue is that the user has to know if they've installed Pg before > (and thus already have a "postgres" service account) or not. Some > clearly don't, or have forgotten the service account password long ago. > > > In general, users expect that an uninstall of an app will remove the > app's configuration. Pg ... sort of ... does. It leaves the user account > in place, though it created it in the first place. So the user has to > know if Pg has been installed previously and if so what the service > account password was. This demonstrably confuses people who try to > uninstall and reinstall Pg to resolve issues (service account > configuration related or other). > If a user has admin rights, he can anytime change the password for an existing 'postgres' user account in case he doesn't remember the password anymore. That said, i believe the text/prompt that asks for password in the installer is clear enough to avoid any confusion. Cant say people actually read all that though. -- Regards, Sachin Srivastava EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres <http://www.enterprisedb.com> company.
On 09/06/10 17:26, Sachin Srivastava wrote: > If a user has admin rights, he can anytime change the password for an > existing 'postgres' user account in case he doesn't remember the > password anymore. ... but people clearly don't know how, given the frequency of questions about this on the lists. I'm sure the majority do, but enough don't that I'm trying to suggest possible usability improvements for the less expert members of the user base. Even some help text pointing them to Control Panel -> Administrative Tools -> Computer Management, then Local Users and Groups would help. Of course, if they change the service account password that way they'll break any existing services using the account. They might also think they're changing the "postgres" cluster user password instead, and get most thoroughly unexpected results when they try to log in next time... > That said, i believe the text/prompt that asks for password in the > installer is clear enough to avoid any confusion. Cant say people > actually read all that though. I don't think it's too by myself, but the number of people asking for help on the lists suggests that it's confusing to some. An enhancement in the installer could remove the need for that. It's nothing more than a suggestion, I just hope you'll consider examining this part of the process in light of some of the questions that turn up on -bugs and -general about this. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/
On Wed, Jun 9, 2010 at 10:03 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> - During the install, test for the existence of a 'postgres' user
> account before displaying the password prompt panel of the installer
> "wizard".
>
> - If such an account does not exist, display the existing UI password
> prompt ui with simplified language indicating that you're creating a new
> password not entering one already set. People seem to struggle with this
> at present.
>
> - If such an account already exists, tell the user that PostgreSQL has
> been installed in the past or another version is currently installed, so
> they must provide the password that was supplied during that prior
> installation. If they do not know the password, they may press an
> offered "reset password" button to enter a new one, but they're warned
> that doing so will cause any other versions of PostgreSQL to stop working.
The current message is:
Please provide a password for the database superuser (${superaccount})
and service account (${serviceaccount}). If the service account
already exists in Windows, you must enter the current password for the
account. If the account does not exist, it will be created when you
click 'Next'.
Or, in upgrade mode:
Please provide a password for service account (${serviceaccount}).
There is a point beyond which further simplification of text really
doesn't help (because people just aren't reading it in the first
place). Personally, I think we're pretty darn close to that point, but
I'm open to better phrasing.
I'm unconvinced that the extra complexity involved in checking the
existence of the service account to tweak the message is worthwhile. I
don't think it buys us extra simplicity that would suddenly make
people understand.
> ------ or possibly ..... --------
>
> - When the postgres user password is reset on the PostgreSQL service via
> the Pg installer, update or offer to update *all* service registrations
> for any service using the postgres account so that they use the same
> password, thus avoiding breaking old versions when the user has
> forgotten the service account password.
That would break any of them that have implemented anything like your
previous suggestion (with the password stored in the registry). Plus,
an installation of PostgreSQL should never modify any other software
that may be installed, imho.
A hint, or button to fire up the computer management MMC might be
feasible, but I'm not entirely sure. I've seen these sort of bug
report from people who have never ventured into the stuff in the
Administrative Tools folder, so even guiding them there may not help.
>> So how would you install something like pgAgent, which you would most
>> likely want to run under the same account?
>
> Installers run as admin; it'd read the registry key during installation
> and use it for the CreateService call.
That might work for one of our installers, but not if someone installs
manually, or using a 3rd party package.
> OTOH, if it's a generated password, leaking it has little effect as it's
> unique to the machine and only grants access to a service account that
> the admin user already has access to by virtue of their admin status on
> that machine.
Which breaks any audit trail because you have no way of knowing which
admin may login as the service user.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
On 09/06/10 18:09, Dave Page wrote: > I'm unconvinced that the extra complexity involved in checking the > existence of the service account to tweak the message is worthwhile. I > don't think it buys us extra simplicity that would suddenly make > people understand. In the end, you know this much better than me, but thanks for listening to me and giving considered comments. Personally I still think the UI is confusing (double-entry of existing password, mixing service account and db superuser into single password) but alternatives may not be any less confusing. In fact, I tried to mock up a few and found that they all required WAY too much knowledge of the difference between the service and db accounts, etc, to be viable, or boiled down to the current one with more babble. Unless service account and db user account are separated (which only makes sense if the service account password management can be made transparent in some way, which it seems it can't really) then the current way is pretty good once you really dig down and compare it to the alternatives. Once again, thanks for taking the time to go through it. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/
On Wed, Jun 9, 2010 at 2:03 PM, Craig Ringer <craig@postnewspapers.com.au> wrote: > On 09/06/10 18:09, Dave Page wrote: > >> I'm unconvinced that the extra complexity involved in checking the >> existence of the service account to tweak the message is worthwhile. I >> don't think it buys us extra simplicity that would suddenly make >> people understand. > > In the end, you know this much better than me, but thanks for listening > to me and giving considered comments. Well we have been through many of these issues before, but that doesn't mean you won't have better ideas that we haven't thought about. > Personally I still think the UI is confusing (double-entry of existing > password, mixing service account and db superuser into single password) > but alternatives may not be any less confusing. In fact, I tried to mock > up a few and found that they all required WAY too much knowledge of the > difference between the service and db accounts, etc, to be viable, or > boiled down to the current one with more babble. FYI, under the hood of the installer, the two passwords are separate, so advanced users can control them independently on the command line. > Unless service account and db user account are separated (which only > makes sense if the service account password management can be made > transparent in some way, which it seems it can't really) then the > current way is pretty good once you really dig down and compare it to > the alternatives. Yeah - we used to have them completely independent in the MSI installers, and some people found that very confusing too. One of the major design aims of the 'one-clicks' was to simplify the process significantly. > Once again, thanks for taking the time to go through it. No problem. Thanks for the ideas. Keep 'em coming :-) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Wed, Jun 9, 2010 at 6:09 AM, Dave Page <dpage@pgadmin.org> wrote:
> Please provide a password for the database superuser (${superaccount})
> and service account (${serviceaccount}). If the service account
> already exists in Windows, you must enter the current password for the
> account. If the account does not exist, it will be created when you
> click 'Next'.
I think that's REALLY confusing. It seems to me that asking for a
password which might be used either to log into an existing account or
to set the password for an account that's about to be created is not
very user-friendly at all. And we get questions about it here
regularly. Why not:
If (account exists)
prompt user to log into account
else
tell user account will be created, ask for account pw
prompt user for db superuser pw
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Wed, Jun 9, 2010 at 10:52 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Wed, Jun 9, 2010 at 3:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Jun 9, 2010 at 6:09 AM, Dave Page <dpage@pgadmin.org> wrote:
>>> Please provide a password for the database superuser (${superaccount})
>>> and service account (${serviceaccount}). If the service account
>>> already exists in Windows, you must enter the current password for the
>>> account. If the account does not exist, it will be created when you
>>> click 'Next'.
>>
>> I think that's REALLY confusing. =A0It seems to me that asking for a
>> password which might be used either to log into an existing account or
>> to set the password for an account that's about to be created is not
>> very user-friendly at all. =A0And we get questions about it here
>> regularly. =A0Why not:
>>
>> If (account exists)
>> =A0prompt user to log into account
>> else
>> =A0tell user account will be created, ask for account pw
>> prompt user for db superuser pw
>
> Because without additional text, the user still doesn't know that
> they're also setting the superuser password for the cluster.
I'm suggesting that you prompt for that separately, as shown in the
above pseudocode. It seems to me that conflating the postgres user
account password with the database superuser password is confusing...
IJWH, of course.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Wed, Jun 9, 2010 at 3:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jun 9, 2010 at 6:09 AM, Dave Page <dpage@pgadmin.org> wrote:
>> Please provide a password for the database superuser (${superaccount})
>> and service account (${serviceaccount}). If the service account
>> already exists in Windows, you must enter the current password for the
>> account. If the account does not exist, it will be created when you
>> click 'Next'.
>
> I think that's REALLY confusing. =A0It seems to me that asking for a
> password which might be used either to log into an existing account or
> to set the password for an account that's about to be created is not
> very user-friendly at all. =A0And we get questions about it here
> regularly. =A0Why not:
>
> If (account exists)
> =A0prompt user to log into account
> else
> =A0tell user account will be created, ask for account pw
> prompt user for db superuser pw
Because without additional text, the user still doesn't know that
they're also setting the superuser password for the cluster.
--=20
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
On Wed, Jun 9, 2010 at 3:57 PM, Robert Haas <robertmhaas@gmail.com> wrote: > I'm suggesting that you prompt for that separately, as shown in the > above pseudocode. =A0It seems to me that conflating the postgres user > account password with the database superuser password is confusing... > IJWH, of course. As I said in a previous email in this thread, having the two password separated also confused people which is why we simplified to one. --=20 Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Thanks to EveryBody! =3D)
---
"Seja em voc=EA a mudan=E7a que quer para o mundo."
Mahatma Gandhi
"A mente que se abre a uma nova id=E9ia jamais voltar=E1 ao seu tamanho
original."
Albert Einstein
JOwEL Henrique
(82) 8830-2627
2010/6/9 Dave Page <dpage@pgadmin.org>
> On Wed, Jun 9, 2010 at 10:03 AM, Craig Ringer
> <craig@postnewspapers.com.au> wrote:
> > - During the install, test for the existence of a 'postgres' user
> > account before displaying the password prompt panel of the installer
> > "wizard".
> >
> > - If such an account does not exist, display the existing UI password
> > prompt ui with simplified language indicating that you're creating a new
> > password not entering one already set. People seem to struggle with this
> > at present.
> >
> > - If such an account already exists, tell the user that PostgreSQL has
> > been installed in the past or another version is currently installed, so
> > they must provide the password that was supplied during that prior
> > installation. If they do not know the password, they may press an
> > offered "reset password" button to enter a new one, but they're warned
> > that doing so will cause any other versions of PostgreSQL to stop
> working.
>
> The current message is:
>
> Please provide a password for the database superuser (${superaccount})
> and service account (${serviceaccount}). If the service account
> already exists in Windows, you must enter the current password for the
> account. If the account does not exist, it will be created when you
> click 'Next'.
>
> Or, in upgrade mode:
>
> Please provide a password for service account (${serviceaccount}).
>
> There is a point beyond which further simplification of text really
> doesn't help (because people just aren't reading it in the first
> place). Personally, I think we're pretty darn close to that point, but
> I'm open to better phrasing.
>
> I'm unconvinced that the extra complexity involved in checking the
> existence of the service account to tweak the message is worthwhile. I
> don't think it buys us extra simplicity that would suddenly make
> people understand.
>
> > ------ or possibly ..... --------
> >
> > - When the postgres user password is reset on the PostgreSQL service via
> > the Pg installer, update or offer to update *all* service registrations
> > for any service using the postgres account so that they use the same
> > password, thus avoiding breaking old versions when the user has
> > forgotten the service account password.
>
> That would break any of them that have implemented anything like your
> previous suggestion (with the password stored in the registry). Plus,
> an installation of PostgreSQL should never modify any other software
> that may be installed, imho.
>
> A hint, or button to fire up the computer management MMC might be
> feasible, but I'm not entirely sure. I've seen these sort of bug
> report from people who have never ventured into the stuff in the
> Administrative Tools folder, so even guiding them there may not help.
>
> >> So how would you install something like pgAgent, which you would most
> >> likely want to run under the same account?
> >
> > Installers run as admin; it'd read the registry key during installation
> > and use it for the CreateService call.
>
> That might work for one of our installers, but not if someone installs
> manually, or using a 3rd party package.
>
> > OTOH, if it's a generated password, leaking it has little effect as it's
> > unique to the machine and only grants access to a service account that
> > the admin user already has access to by virtue of their admin status on
> > that machine.
>
> Which breaks any audit trail because you have no way of knowing which
> admin may login as the service user.
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise Postgres Company
>