Thread: I "might" have found a bug on 8.2.1 win32
I had installed the win32 version awhile ago, but I had the pg_hba.conf set to trust. Then I started to test SSL on win32 so I changed it to this: host all all 127.0.0.1/32 md5 host all all 192.168.15.131/32 md5 #my pcs adddress And I ensured the service had been restarted after making the change to md5 instead of trust for my PC address. Ok, here is the problem, If I pass in a blank password '' the md5 authentication is not done and I simply go right in with full access. If I pass in a space ' ' the I get the password authentication error. Normally with a blank password I would expect to see the no password supplied error, but that is not happening on win32 it just gives full blown access. Here is the connect string being passed to libpq.dll when I use the blank password, this string is captured from the debugger: hostaddr='10.201.170.131' port='5432' dbname='template1' user='postgres' password='' connect_timeout='15' sslmode=disable I tried the same thing on a Linux server and it does not behave this way, only on win32. I then uninstalled 8.2.1 on the win32 box and completely deleted the data directory and reinstalled and the same behavior prevailed. I know a new connect GRANT was enabled in 8.2, but I though that was in addition to the first checks done in pg_hba.conf. Maybe I am doing something wrong, but it sure doesn't seem that way. Like I said it "might" be a bug. -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
Tony Caduto wrote: > I had installed the win32 version awhile ago, but I had the pg_hba.conf > set to trust. Then I started to test SSL on win32 so I changed it to this: > host all all 127.0.0.1/32 md5 > host all all 192.168.15.131/32 md5 #my pcs adddress > > And I ensured the service had been restarted after making the change to > md5 instead of trust for my PC address. > > Ok, here is the problem, If I pass in a blank password '' the md5 > authentication is not done and I simply go right in with full access. > If I pass in a space ' ' the I get the password authentication error. > Normally with a blank password I would expect to see the no password > supplied error, but that is not happening on win32 it just gives full > blown access. > > Here is the connect string being passed to libpq.dll when I use the > blank password, this string is captured from the debugger: > > hostaddr='10.201.170.131' port='5432' dbname='template1' user='postgres' > password='' connect_timeout='15' sslmode=disable > > I tried the same thing on a Linux server and it does not behave this > way, only on win32. > > I then uninstalled 8.2.1 on the win32 box and completely deleted the > data directory and reinstalled and the same behavior prevailed. > > I know a new connect GRANT was enabled in 8.2, but I though that was in > addition to the first checks done in pg_hba.conf. > > Maybe I am doing something wrong, but it sure doesn't seem that way. > Like I said it "might" be a bug. > > > Question, I hope stupid, postgres user HAS a password right?
> > Question, I hope stupid, postgres user HAS a password right? > Yes, it has a password, I set the password from the installer, and I even reset it after the install was complete. I just tried this from the command line and it let me right in: psql template1 -U postgres Didn't ask for a password or anything, and the localhost entry in pg_hba.conf is also set for md5. -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
In response to Tony Caduto <tony_caduto@amsoftwaredesign.com>: > > > > Question, I hope stupid, postgres user HAS a password right? > > > Yes, it has a password, I set the password from the installer, and I > even reset it after the install was complete. > I just tried this from the command line and it let me right in: > > psql template1 -U postgres > > Didn't ask for a password or anything, and the localhost entry in > pg_hba.conf is also set for md5. Does Windows have the equivalent of Unix domain sockets? On a Unix machine, psql uses unix domain sockets by default, which are controlled by an entry like: # "local" is for Unix domain socket connections only local all all trust The following entry: # IPv4 local connections: host all all 127.0.0.1/32 trust Will only apply if you connect via loopback networking (which is not psql's default). Try your connect command like this: psql template1 -U postgres -h 127.0.0.1 and see if the results change. -- Bill Moran Collaborative Fusion Inc.
Bill Moran wrote: > > Will only apply if you connect via loopback networking (which is not > psql's default). Try your connect command like this: > psql template1 -U postgres -h 127.0.0.1 > and see if the results change. > > Hi Bill, Using the -h 127.0.0.1 does cause the password prompt to fire, however the weird part is in my pg_hba.conf I also have the local entry set to md5 local all all md5 I did some more testing and it seems the password I used during the win32 install is being cached somewhere. If I don't change the password from the one I used during the install it lets me right in, if I change the password to something else I get a password authentication error with a blank password, if I then change the postgres password back to the one I used during install a blank password again lets me right in. I have not done a reboot yet, I will do reboot and see if that clears it up. -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
Well, there is something weird going on here:
If I change the postgres users password to the one I used during install
I get this when using psql:
C:\Program Files\PostgreSQL\8.2\bin>psql template1 -U postgres
DEBUG: InitPostgres
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid
1348/1/0, nestlvl: 1, children: <>
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid
1348/1/0, nestlvl: 1, children: <>
Welcome to psql 8.2.1, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
Warning: Console code page (437) differs from Windows code page (1252)
8-bit characters may not work correctly. See psql reference
page "Notes for Windows users" for details.
template1=#
If I change the password to anything else I get this:
C:\Program Files\PostgreSQL\8.2\bin>psql template1 -U postgres
psql: FATAL: password authentication failed for user "postgres"
I did a search for a password file but it came back empty.
Anyone have any ideas on why this is happening?
--
Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning Admin for Postgresql
Your best bet for Postgresql Administration
Tony Caduto <tony_caduto@amsoftwaredesign.com> writes:
> I just tried this from the command line and it let me right in:
> psql template1 -U postgres
> Didn't ask for a password or anything, and the localhost entry in
> pg_hba.conf is also set for md5.
You sure you restarted the postmaster (or did pg_ctl reload) after
changing the pg_hba.conf file? Is it possible there's another
postmaster on the machine that's the one you're actually connecting to?
Also, since you evidently did not show us all of pg_hba.conf the first
time, let's see it all.
regards, tom lane
Never mind, somehow a application setup a pgpass.conf file for me without my knowledge. Sorry it's not a bug. However I wonder if it might be a good idea if psql would raise a warning after logon that a pgpass.conf file was used for authentication or have it written to the log. I am sure some 3rd party application I was testing created the file when it took my server login information. I would have found out about it right away if it's use would have been written to the log. Thanks everyone for you help. -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
Tony Caduto wrote: > Never mind, > somehow a application setup a pgpass.conf file for me > without my knowledge. Have you been leaving the dark side lately? (pgAdmin does this..) > Sorry it's not a bug. However I wonder if it might be a good idea if > psql would raise a warning after logon that a pgpass.conf file was used > for authentication or have it written to the log. I am sure some 3rd > party application I was testing created the file when it took my server > login information. I would have found out about it right away if it's > use would have been written to the log. psql can't do this, really, because that part happens entirely in libpq. We'd need extra API for this. IIRC, I suggested this before, but I can't remember what the result with. Running out of batteries ATM, so no time to look it up in the archives ;-) //Magnus
Magnus Hagander wrote: > > Have you been leaving the dark side lately? > (pgAdmin does this..) > > > I still have pgAdmin installed :-) it's a good reference tool. I imagine you guys are using it for the pg_restore/pg_dump? There really should be a pg_dump.dll and a pg_restore.dll so a pgpass file would not be needed. The microolap guys have created the dlls and it's what I use now for my dump/restore operations. Is there a way to tell libpq in the connection string or something not to use a pgpass.conf file? I looked in the libpq docs but didn't really see anything. I kind of don't like the way the pgpass file affected all the apps that used libpq, it could be considered a security risk. -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
Tony Caduto <tony_caduto@amsoftwaredesign.com> writes:
> Is there a way to tell libpq in the connection string or something not
> to use a pgpass.conf file? I looked in the libpq docs but didn't really
> see anything.
Making pgpass files harder or more annoying to use does not strike me as
a good idea. I realize you're a bit ticked off right now, but for the
vast majority of users they're a very nice feature.
regards, tom lane
> ------- Original Message ------- > From: Tony Caduto <tony_caduto@amsoftwaredesign.com> > To: Bill Moran <wmoran@collaborativefusion.com> > Sent: 01/02/07, 17:13:25 > Subject: Re: [GENERAL] I "might" have found a bug on 8.2.1 win32 > > Bill Moran wrote: > > > > Will only apply if you connect via loopback networking (which is not > > psql's default). Try your connect command like this: > > psql template1 -U postgres -h 127.0.0.1 > > and see if the results change. > > > > > Hi Bill, > > Using the -h 127.0.0.1 does cause the password prompt to fire, however > the weird part is in my pg_hba.conf I also have the local entry set to md5 > > local all all md5 > > > I did some more testing and it seems the password I used during the > win32 install is being cached somewhere. > If I don't change the password from the one I used during the install it > lets me right in, if I change the password to something else I get a > password > authentication error with a blank password, if I then change the > postgres password back to the one I used during install a blank password > again lets me right in. I have not done a reboot yet, I will do reboot > and see if that clears it up. Could this be proof of you using pgAdmin ( :-) ) and checking the Store Password option? That'll save it in pgpass.conf inyour profile. /D
Dave Page wrote: > Could this be proof of you using pgAdmin ( :-) ) and checking the Store Password option? That'll save it in pgpass.confin your profile. > > /D > > I won't deny I have it installed :-) I don't remember using the stored password option though. Do you also use that for the pg_restore/pg_dump so you don't have to pipe the password? Why don't you just store the password in a file in the same directory as the pgAdmin executable? That way it would not affect other applications. Later, -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
> ------- Original Message ------- > From: Tony Caduto <tony_caduto@amsoftwaredesign.com> > To: Magnus Hagander <magnus@hagander.net>, pgsql-general@postgresql.org > Sent: 01/02/07, 18:38:22 > Subject: Re: [GENERAL] I "might" have found a bug on 8.2.1 win32 > > I imagine you guys are using it for the pg_restore/pg_dump? No, we use %PGPASSWORD% for that. pgAdmin stores the password there if you use the Store Password connection option. /D
> ------- Original Message ------- > From: Tony Caduto <tony_caduto@amsoftwaredesign.com> > To: Dave Page <dpage@postgresql.org> > Sent: 01/02/07, 20:17:00 > Subject: Re: [GENERAL] I "might" have found a bug on 8.2.1 win32 > > I won't deny I have it installed :-) I don't remember using the stored > password option though. > Do you also use that for the pg_restore/pg_dump so you don't have to > pipe the password? > > Why don't you just store the password in a file in the same directory as > the pgAdmin executable? That way it would not affect other > applications. A non-admin user wouldn't necessarily be able to edit it, and it would be shared amongst all users of the machine. /D
> ------- Original Message ------- > From: Tony Caduto <tony_caduto@amsoftwaredesign.com> > To: Dave Page <dpage@postgresql.org> > Sent: 01/02/07, 20:37:18 > Subject: Re: [GENERAL] I "might" have found a bug on 8.2.1 win32 > > Dave Page wrote: > > A non-admin user wouldn't necessarily be able to edit it, and it would be shared amongst all users of the machine. > > > > /D > > > > > Well, there has to be a way so it won't affect other applications. > I don't want to start deleting it when LA starts up. (which I could do > with one line of code) That's a good way to cheese users off. > Is there a way to tell the libpq connect function not to use a pgpass > file? No, as Tom already said. > It really should be up to the application if it wants to use it > or not. No, it should be up to the *user* to decide, which is why it's a non-default (iirc) option in pgAdmin. /D
> Is there a way to tell the libpq connect function not to use a pgpass > file? No, as Tom already said.
I think you could effectively disable the pgpass file (for a given application) if the application always requires an explicit, non-blank password from the user.
libpq won't use .pgpass if the connection string passed to PQconnectdb() (or whatever connection function you happen to be using) includes a "password=foo" clause, right?
-- Korry
<korryd@enterprisedb.com> writes:
> I think you could effectively disable the pgpass file (for a given
> application) if the application always requires an explicit, non-blank
> password from the user.
If he does that, his users who do not use password-based authentication
will be after him with the proverbial villagers' implements.
regards, tom lane
> I think you could effectively disable the pgpass file (for a given > application) if the application always requires an explicit, non-blank > password from the user. If he does that, his users who do not use password-based authentication will be after him with the proverbial villagers' implements.
True... perhaps I missed that part of the thread. Of course my suggestion would only affect the one application (which I think is what Tony was looking for).
-- Korry
> ------- Original Message ------- > From: Tony Caduto <tony_caduto@amsoftwaredesign.com> > To: Dave Page <dpage@postgresql.org> > Sent: 01/02/07, 21:18:49 > Subject: Re: [GENERAL] I "might" have found a bug on 8.2.1 win32 > > I may be forced to start deleting the pgpass file unless we can work > something out. I must Be missing the point - why should I work something out with your app for using a documented feature of libpq in pgAdmin? > I saw in the docs you can specify a alternate location for the pgpass > file, why don't you guys use some other location so you are not > impacting other > apps? If a user goes into %APPDATA%\postgresql\pgpass.conf with the > specific purpose of setting up a pgpass file so they don't have to enter > a password that's a differnt story. Because PGPASSFILE only appeared in 8.1 and we don't know if our libpq supports it at runtime. > Not to mention that the whole pgpass thing is a huge security hole, it > would be different if the passwords where encrypted or hashed, but they > are just sitting there in plain text. In an 0600 file on *nix, or in your profile on Windows, which if you were concerned with security would be secured as well. > If you have a way to prevent my app from automatically using settings > set by pgAdmin III, I am willing to listen. To what? I'm not the one wanting to change anything! :-) /D
On Thu, Feb 01, 2007 at 12:38:22PM -0600, Tony Caduto wrote: > Magnus Hagander wrote: > > > >Have you been leaving the dark side lately? > >(pgAdmin does this..) > > > > > > > I still have pgAdmin installed :-) it's a good reference tool. :-) > Is there a way to tell libpq in the connection string or something not > to use a pgpass.conf file? I looked in the libpq docs but didn't really > see anything. > > I kind of don't like the way the pgpass file affected all the apps that > used libpq, it could be considered a security risk. it can be annoying. I personally don't like that pgAdmin does it, because I would like the "save password" feature to just save it for pgAdmin. But that's me, and I've accepted that I'm in minority. However, I don't think you can get away with calling it a security risk. It can be an annoying thing for some people in some sitatuions, but it's not a security risk. //Magnus
On Thu, Feb 01, 2007 at 09:53:26PM -0000, Dave Page wrote: > > Not to mention that the whole pgpass thing is a huge security hole, it > > would be different if the passwords where encrypted or hashed, but they > > are just sitting there in plain text. > > In an 0600 file on *nix, or in your profile on Windows, which if you were concerned with security would be secured as well. Not to mention it's secured by default, and you'd actually have to go out of your way to make it *unsecure*. (Yes, one common way to make it unsecure is to make every local user an administrator is a comon way to break it, but if you do that you have so many other ways ot hack that system it doesn' tmake a real difference) //Magnus
On Thu, Feb 01, 2007 at 02:17:00PM -0600, Tony Caduto wrote: > Dave Page wrote: > >Could this be proof of you using pgAdmin ( :-) ) and checking the Store > >Password option? That'll save it in pgpass.conf in your profile. > > > >/D > > > > > I won't deny I have it installed :-) I don't remember using the stored > password option though. > Do you also use that for the pg_restore/pg_dump so you don't have to > pipe the password? > > Why don't you just store the password in a file in the same directory as > the pgAdmin executable? That way it would not affect other > applications. That would of course break every sensible windows install in the world, but other than that is'a good idea ;-) Seriously, it could store it in a separate file for pgAdmin, but then you would run into the issue of pg_dump and such I guess. //Magnus
Dave Page wrote: > > I must Be missing the point - why should I work something out with your app for using a documented feature of libpq inpgAdmin? > > > Dave, The whole point is pgAdmin III is storing the password in the pgpass file which is global for every single application that uses it, don't you see the problem? It's clear as crystal!!!! pgAdmin III should be storing the password on win32 in the registry like every other win32 program does, or in a ini file, it's the accepted way to do that sort of thing on win32. It just is, and the way you are doing it is not the way it should be done in the win32 world. I was just asking that we work together to find a way our applications would not affect each other, and currently pgAdmin III is the clear violator by using a global feature of libpq to store passwords for its own use without regard for other applications that may be using libpq. I don't think the pgpass file was intended to be used as a password storage method for pgAdmin III, it was meant as a way to allow psql and other command line programs to be easily used from scripts where it would be detrimental to have a password prompt pop up during a scheduled run or maybe I am wrong and it was created just for the use of pgAdmin III but that does not really matter. I am sorry, but I believe the way pgAdmin III is using the pgpass file is TOTALLY WRONG, sorry but it just is. It's global to every single app that uses libpq on the PC, I just don't understand why you don't get it. The way you make it sound is like pgAdmin III does not want to play nice with other applications, and I can do that to. I don't want to delete the pgpass file, but I will so my application gets the same rights as pgAdmin III. I have users who set their test servers to trust and why should I make them store a password when they don't need to? That's what I would have to do, force the user to enter some form of password, so it's not blank or force them to store a password even if the server is set for trust access. Sorry in advance if you don't like what I have to say, but sometimes you can be very stubborn and one way or the highway!!! Later, -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
Tony Caduto wrote: > Dave Page wrote: >> > I am sorry, but I believe the way pgAdmin III is using the pgpass file > is TOTALLY WRONG, sorry but it just is. Actually, no, it's using it *exactly as it's documented* - which is not unlike any other win32 app. For example, if you use the IE ActiveX control to display web pages in your app, it will remember passwords you save there for reuse in Internet Explorer, the HTML Help reader or any other apps that use the IE control. > The way you make it sound is like pgAdmin III does not want to play nice > with other applications, and I can do that to. > I don't want to delete > the pgpass file, but I will so my application gets the > same rights as pgAdmin III. No, what I'm saying is that pgAdmin is using a documented feature of libpq, and allowing users to save and edit pgpass.conf/.pgpass files to store the passwords for all their libpq apps. What you are saying is that because you don't believe in the pgpass design, you are going to summarily delete them - which I know for absolute sure would *really* annoy some pgAdmin users that I know for a fact have a whole heap of passwords stored in theirs. Doing that would only hurt your products reputation, not mine. > I have users who set their test servers to > trust and why should I make them store a password when they don't need > to? That's what I would have to do, force the user to enter some form of > password, so it's not blank or force them to store a password even if > the server is set for trust access. pgAdmin doesn't force them to store any passwords at all. That's pure FUD. > Sorry in advance if you don't like what I have to say, but sometimes you > can be very stubborn and one way or the highway!!! I know - and that's a policy that has served me very well in life. I will listen to other ideas, but unless I'm thoroughly convinced they are better I'm not going to change my mind in a hurry. Regards, Dave
Dave Page wrote: > > pgAdmin doesn't force them to store any passwords at all. That's pure > FUD. > You are correct on that fact Dave, however it does force them to store the password in a pgpass file without their knowledge. When you check that box "Store Password" it is not warning the user that a pgpass file will be created and that it will affect all applications that use libpq for that particular host. So a user selects store password in pgAdmin III, then they need to use psql for some reason and yipee skipee they get automagically authenticated when they attempt to connect to that host. I had know idea pgAdmin III was using pgpass to store the password, I thought something was wrong with my servers pg_hba.conf file or a it was a bug. It just totally amazes me that you don't see the big picture problem with pgAdmin III using pgpass. The only other solution to this problem beside the pgAdmin III team fixing the inappropriate use of pgpass is to make a change to libpq by adding a new connections string option to ignore the pgpass file. At least that way the developer of the application would have the choice to use pgpass or not. Later, -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
Dave Page wrote: > > What you are saying is that because you don't believe in the pgpass > design, you are going to summarily delete them - which I know for > absolute sure would *really* annoy some pgAdmin users that I know for > a fact have a whole heap of passwords stored in theirs. Doing that > would only hurt your products reputation, not mine. > Dave, My product is not storing passwords using pgpass without the users knowledge. If pgAdmin III stored it's own passwords in the registry it would be up to the user (as it should be) to use pgpass. If they chose to use pgpass, libpq would override the passwords stored in the registry anyway, which is what pgAdmin III is doing automatically to my application without my or my users consent. pgAdmin III is corrupting the intended use of pgpass. It seems you guys did it as a shortcut so you wouldn't have to write your own password storage code which is not that difficult to do anyway. If you guys are at all interested in doing the right thing you will take this very seriously and find a way to fix it. I know you think I am being a pain, but I am just sticking to my guns on what I KNOW is right. Later, -- Tony Caduto AM Software Design http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql Your best bet for Postgresql Administration
Tony Caduto wrote: > Dave Page wrote: >> >> Actually, no, it's using it *exactly as it's documented* - which is >> not unlike any other win32 app. For example, if you use the IE ActiveX >> control to display web pages in your app, it will remember passwords >> you save there for reuse in Internet Explorer, the HTML Help reader or >> any other apps that use the IE control. >> > > Dave, > You guys need to make the pgAdmin III password storage private to > pgAdmin III. > You are indeed using a documented feature of libpq, but that does not > mean you are using it properly. I'm not sure that's something you can say with authority given that I'm fairly sure you have no idea what the original authors intent was, and that nowhere in the documentation does it say that only command line tools should use the feature. > What you have done is not right because you have not taken into > consideration that there are other 3rd party apps that use libpq, and > because you have chosen to take a shortcut in the password storage area, > it affects my application without my users knowledge. We *have* taken that into account, we have documented it, and we have provided a UI for the user to make their own tweaks. > Sure I am the only one who noticed this as of now, but there will be > others and I am sure they won't like it either. Just do the right thing > and make the change. I don't want to delete the darn file, but you will > leave me no choice, or maybe I will rename it while my app is running > and then > rename it back when my app is finished. I really shouldn't have to do > this. Why don't you just check to see if a matching entry is in the file and warn your users? That way they'll know whether pgAdmin set it up for them, a colleague did it, or even that they did it and subsequently forgot. > You guys need to step up to the plate and make the password storage > private to pgAdmin III, you can do this by using: > > PGPASSFILE (specifies the name of the password file to use for lookups) > or use a compiler directive and store it (the password) in > HKEY_CURRENT_USER in the registry or use a INI type file stored in the > users profile (Application Data on win32 users home directory on > Unix/Linux) > The second two options are probably the best. You could even use the > opportunity to make pgAdmin III better by encrypting the passwords so > they are not in plain text. I can guarantee that a auditor would find > fault with the use of pgpass anyway as it is totally not secure, and > don't try to tell me it is secure, anytime passwords are sitting on a > storage device in plain text it's a security risk. The first option won't work, for reasons I've already stated. The second options are barely any more secure than the current situation as the app would need to use reversible encryption, the key for which could never be kept secret (it's Open Source after all). > Leave the use of pgpass to the user for use with command line tools. > > I am not being unreasonable here. What I have brought to your attention > is a valid concern that NEEDS to be addressed. > In the past you have asked me to make changes to my website and I always > tried to accommodate your concerns, now it's your turn to consider one > of mine. That was entirely different - you were intentionally bad-mouthing and inaccurately describing pgAdmin in order to sell your own product!! I do not intend to rewrite this code (which has been in pgAdmin for years) on the basis of a single complaint from the author of an equivalent, but commercial tool. If you do not like the effects you see when a user has a pgpass file, you should warn them in your own code, not expect us to change ours to avoid using a documented feature of libpq. Regards, Dave.
Tony Caduto <tony_caduto@amsoftwaredesign.com> writes:
> You are correct on that fact Dave, however it does force them to store
> the password in a pgpass file without their knowledge.
This seems about on par with arguing that pgAdmin forces users to store
data in a database without their knowledge. Worse yet, other programs
could possibly look into the database and see it!
Tony, nobody is buying your argument. Give it a rest.
regards, tom lane
Tony Caduto wrote: > If pgAdmin III stored it's own passwords in the registry it would be up > to the user (as it should be) to use pgpass. > If they chose to use pgpass, libpq would override the passwords stored > in the registry anyway, which is what pgAdmin III is doing > automatically to my application without my or my users consent. It strikes me that the root of this is who/what is authenticating. Tony would like it to be his application (or rather libpq on behalf of his application). In fact, it is the OS-user (or rather libpq on behalf of the user). Since it is the OS-user that libpq deals with, it strikes me as right that the pgpass file should be shared by all apps. I'd expect my ssh config to be available to any ssh-based apps - scp / sftp etc, since it's clear that's user-based config. On the other hand, I'd be surprised if two email clients shared account/password details. Although, it might be nice if they did. I wonder if the Mac's keyring manages that sort of thing? And I'm endlessly irritated that my various web-browsers don't automatically share bookmarks. So - since there is at least one user who's suprised by this behaviour, we probably need two things: 1. A message that tells users the password is being remembered for *them* rather than for pgAdmin. 2. A simple way to allow an application to act independently of the user-wide configuration. Or perhaps just better explanation in the docs. -- Richard Huxton Archonet Ltd
Re: Re: pgAdmin III and pgpass was I "might" have found a bug on 8.2.1 win32
From
"Joshua D. Drake"
Date:
>> Leave the use of pgpass to the user for use with command line tools.
>>
>> I am not being unreasonable here. What I have brought to your attention
>> is a valid concern that NEEDS to be addressed.
>> In the past you have asked me to make changes to my website and I always
>> tried to accommodate your concerns, now it's your turn to consider one
>> of mine.
>
> That was entirely different - you were intentionally bad-mouthing and
> inaccurately describing pgAdmin in order to sell your own product!!
>
> I do not intend to rewrite this code (which has been in pgAdmin for
> years) on the basis of a single complaint from the author of an
> equivalent, but commercial tool. If you do not like the effects you see
> when a user has a pgpass file, you should warn them in your own code,
> not expect us to change ours to avoid using a documented feature of libpq.
Tony,
I believe you are being unreasonable here for a couple of reasons.
1. pgpass.conf is a known, documented feature of libpq. This is not
something that PgAdmin decided to do willy nilly.
2. It should be expected that 3rd party application that are for
PostgreSQL work the way PostgreSQL expects them to. That means pgpass.conf.
Per #2, that means that your application, should you want it to work the
way PostgreSQL expects, needs to take into account that there may be a
pgpass.conf available.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Tony Caduto wrote: > Dave Page wrote: >> >> What you are saying is that because you don't believe in the pgpass >> design, you are going to summarily delete them - which I know for >> absolute sure would *really* annoy some pgAdmin users that I know for >> a fact have a whole heap of passwords stored in theirs. Doing that >> would only hurt your products reputation, not mine. >> > Dave, > > My product is not storing passwords using pgpass without the users > knowledge. > If pgAdmin III stored it's own passwords in the registry it would be up > to the user (as it should be) to use pgpass. > If they chose to use pgpass, libpq would override the passwords stored > in the registry anyway, which is what pgAdmin III is doing > automatically to my application without my or my users consent. > > pgAdmin III is corrupting the intended use of pgpass. It seems you guys > did it as a shortcut so you wouldn't have to write your own password > storage > code which is not that difficult to do anyway. You think that's a shortcut? It's far harder to automatically maintain that file without screwing up user entries than it would be for us to store the password alongside the other connection details - that's a 100 line vs. 1 line kind of ratio!! Using pgpass was intentional, as was the fact we made it option, as was the fact that we documented the effects and consequences of saving the password, as was the fact that we also have an editor for users to manually tweak the file if they wish. Regards, Dave
Richard Huxton <dev@archonet.com> writes:
> So - since there is at least one user who's suprised by this behaviour,
> we probably need two things:
> 1. A message that tells users the password is being remembered for
> *them* rather than for pgAdmin.
> 2. A simple way to allow an application to act independently of the
> user-wide configuration. Or perhaps just better explanation in the docs.
Possibly just another word or two in the "Store Password" button name
would fix the disagreement. I agree that it's not totally clear that
it's going to store it for all the user's PG use rather than just
pgAdmin.
regards, tom lane
Tom Lane wrote: > Richard Huxton <dev@archonet.com> writes: >> So - since there is at least one user who's suprised by this behaviour, >> we probably need two things: >> 1. A message that tells users the password is being remembered for >> *them* rather than for pgAdmin. >> 2. A simple way to allow an application to act independently of the >> user-wide configuration. Or perhaps just better explanation in the docs. > > Possibly just another word or two in the "Store Password" button name > would fix the disagreement. I agree that it's not totally clear that > it's going to store it for all the user's PG use rather than just > pgAdmin. pgAdmin has a feature call Guru Hints which I was thinking of using in this case - we can give more info about the file, and how to use the pgpass editor in there. Regards, Dave.
Tony Caduto wrote:
> Dave Page wrote:
> >
> > What you are saying is that because you don't believe in the pgpass
> > design, you are going to summarily delete them - which I know for
> > absolute sure would *really* annoy some pgAdmin users that I know for
> > a fact have a whole heap of passwords stored in theirs. Doing that
> > would only hurt your products reputation, not mine.
> >
> Dave,
>
> My product is not storing passwords using pgpass without the users
> knowledge.
> If pgAdmin III stored it's own passwords in the registry it would be up
> to the user (as it should be) to use pgpass.
> If they chose to use pgpass, libpq would override the passwords stored
> in the registry anyway, which is what pgAdmin III is doing
> automatically to my application without my or my users consent.
You can disable reading .pgpass by defining the PGPASSFILE environment
variable to point to a non-existant file. This works for all
applications that use libpq.
Here is a funny parable about what happens when you try to please
everybody:
http://www.bartleby.com/17/1/62.html
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
> So - since there is at least one user who's suprised by this behaviour,
> we probably need two things:
> 1. A message that tells users the password is being remembered for
> *them* rather than for pgAdmin.
Well that is up to the pgAdmin team but I would agree that if pgAdmin is
going to continue the behavior that it should be explicit, something like:
Saving your password with pgAdmin for user Windows user foo.
Heck you could even sell it as a feature.
> 2. A simple way to allow an application to act independently of the
> user-wide configuration. Or perhaps just better explanation in the docs.
Other apps can just null the environment variable.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Re: Re: pgAdmin III and pgpass was I "might" have found a bug on 8.2.1 win32
From
Magnus Hagander
Date:
> I do not intend to rewrite this code (which has been in pgAdmin for > years) on the basis of a single complaint from the author of an > equivalent, but commercial tool. If you do not like the effects you see > when a user has a pgpass file, you should warn them in your own code, > not expect us to change ours to avoid using a documented feature of libpq. Ok, as most of the regular readers know, I don't often agree with Tony (so open your eyes, you may never see this again!), but really Dave, that's not a true statement. I know for a fact that I have complained about this feature at least once (I think twice) and we had a pretty long discussion about it. And I like to see myself as a developer on the project, and not a commercial tool ;-) I have been bitten by this myself. Even after I knew it. And I know others who have been. *I* think that pgAdmin *should* store the password along with the rest of the connection options, or at least make it an option to do so instead. But there was a discussion, and I was in minority, so I bowed to the majority vote. And I still do. Doesn't mean I think it's right ;-) But I'm not going to go and commit a change for it. //Magnus
Magnus Hagander wrote: >> I do not intend to rewrite this code (which has been in pgAdmin for >> years) on the basis of a single complaint from the author of an >> equivalent, but commercial tool. If you do not like the effects you see >> when a user has a pgpass file, you should warn them in your own code, >> not expect us to change ours to avoid using a documented feature of libpq. > > Ok, as most of the regular readers know, I don't often agree with Tony > (so open your eyes, you may never see this again!), but really Dave, > that's not a true statement. I know for a fact that I have complained > about this feature at least once (I think twice) and we had a pretty > long discussion about it. And I like to see myself as a developer on the > project, and not a commercial tool ;-) I honestly don't remember that. I do recall you commenting to that effect in response to Tony though. Regards, Dave.
Re: Re: pgAdmin III and pgpass was I "might" have found a bug on 8.2.1 win32
From
Magnus Hagander
Date:
Dave Page wrote: > Magnus Hagander wrote: >>> I do not intend to rewrite this code (which has been in pgAdmin for >>> years) on the basis of a single complaint from the author of an >>> equivalent, but commercial tool. If you do not like the effects you see >>> when a user has a pgpass file, you should warn them in your own code, >>> not expect us to change ours to avoid using a documented feature of libpq. >> Ok, as most of the regular readers know, I don't often agree with Tony >> (so open your eyes, you may never see this again!), but really Dave, >> that's not a true statement. I know for a fact that I have complained >> about this feature at least once (I think twice) and we had a pretty >> long discussion about it. And I like to see myself as a developer on the >> project, and not a commercial tool ;-) > > I honestly don't remember that. I do recall you commenting to that > effect in response to Tony though. My arguments must've sucked if they failed so completely to make an impression. I think we discussed this in Tokyo actually. And I lost out to both you and Andreas. //Magnus
Magnus Hagander wrote: > Dave Page wrote: >> Magnus Hagander wrote: >>>> I do not intend to rewrite this code (which has been in pgAdmin for >>>> years) on the basis of a single complaint from the author of an >>>> equivalent, but commercial tool. If you do not like the effects you see >>>> when a user has a pgpass file, you should warn them in your own code, >>>> not expect us to change ours to avoid using a documented feature of libpq. >>> Ok, as most of the regular readers know, I don't often agree with Tony >>> (so open your eyes, you may never see this again!), but really Dave, >>> that's not a true statement. I know for a fact that I have complained >>> about this feature at least once (I think twice) and we had a pretty >>> long discussion about it. And I like to see myself as a developer on the >>> project, and not a commercial tool ;-) >> I honestly don't remember that. I do recall you commenting to that >> effect in response to Tony though. > > My arguments must've sucked if they failed so completely to make an > impression. > > I think we discussed this in Tokyo actually. And I lost out to both you > and Andreas. Oh, I was probably drunk then :-p /D
Re: Re: pgAdmin III and pgpass was I "might" have found a bug on 8.2.1 win32
From
Magnus Hagander
Date:
Dave Page wrote: > Magnus Hagander wrote: >> Dave Page wrote: >>> Magnus Hagander wrote: >>>>> I do not intend to rewrite this code (which has been in pgAdmin for >>>>> years) on the basis of a single complaint from the author of an >>>>> equivalent, but commercial tool. If you do not like the effects you see >>>>> when a user has a pgpass file, you should warn them in your own code, >>>>> not expect us to change ours to avoid using a documented feature of libpq. >>>> Ok, as most of the regular readers know, I don't often agree with Tony >>>> (so open your eyes, you may never see this again!), but really Dave, >>>> that's not a true statement. I know for a fact that I have complained >>>> about this feature at least once (I think twice) and we had a pretty >>>> long discussion about it. And I like to see myself as a developer on the >>>> project, and not a commercial tool ;-) >>> I honestly don't remember that. I do recall you commenting to that >>> effect in response to Tony though. >> My arguments must've sucked if they failed so completely to make an >> impression. >> >> I think we discussed this in Tokyo actually. And I lost out to both you >> and Andreas. > > Oh, I was probably drunk then :-p Hmm. Ok, my arguments must *REALLY* have sucked then. Man, you're not helping my confidence here! //Magnus