Re: [GENERAL] password

[Wes Williams]

What 
platform?  Solaris, FreeBSD, Linux, Windows
 

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]On Behalf Of Michael 
  UvhagenSent: Friday, October 21, 2005 6:10 AMTo: 
  pgsql-general@postgresql.orgSubject: [GENERAL] 
  passwordHi.I was installing postgresql 8.0 and let it 
  generate a password for me, then i changed my mind and went back to change the 
  password, but then i was stuck. How do i find the password it generated for 
  me? How do i change it? How can i start over and install postgresql somehow? 
  Thanks!/Mike

Re: [GENERAL] password

[Magnus Hagander]

> Hi.
> I was installing postgresql 8.0 and let it generate a 
> password for me, then i changed my mind and went back to 
> change the password, but then i was stuck. How do i find the 
> password it generated for me? How do i change it? How can i 
> start over and install postgresql somehow? Thanks!

If you didn't write it down, you can't get back at it :-)

For 8.1, we won't use the password until you've actually clicked the
"finish" button to go through the install, so it'll work better there.

For 8.0, what you do is you manually remove the postgres account it
created, and start over. YOu can do this using "net user postgres
/delete" or from the windows GUI.

//Magnus

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [GENERAL] password

[Sachin Srivastava]

Hello,

Installation of postgresql requires you to enter a password for the user 
'postgres'.

 i) If the user 'postgres' is not there, it will create it and set the password 
to whatever you have provided,
 ii) If the user 'postgres' is already existing, then you have to give its 
password to move further in the installation.

You can use any account other that 'postgres' by giving CLI option 
'---serviceaccount '. See --help for more details.

In case you dont remember the password you set for user 'postgres' then you can 
change the same via "Right Click My Computer"-->"Manage"-> Users.. 

You said it rejects the password.  When ? 

And windows user are most welcome here.


On Feb 21, 2011, at 7:40 AM, Roedy Green wrote:

> I gave Postgre a password during install.  However, it always rejects
> it. I tried uninstalling, deleting all files, and reinstalling. Same
> thing.  It complains about user "roedy" (my windows id). It seems to
> me the default user is supposed to be postgres not Roedy.  Perhaps
> that is the source of the problem. I can't find anything relevant in
> the docs.
> 
> The docs talk about installing on Unix by compiling C source.  I have
> Windows 7 64 bit. I get the feeling Windows users are unwelcome.
> -- 
> Roedy Green Canadian Mind Products
> http://mindprod.com
> Refactor early. If you procrastinate, you will have
> even more code to adjust based on the faulty design.
> .
> 
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

--
Regards,
Sachin Srivastava
EnterpriseDB, the Enterprise PostgreSQL company.

Re: [GENERAL] password

[John R Pierce]

On 02/20/11 9:15 PM, Sachin Srivastava wrote:
In case you dont remember the password you set for user 'postgres' 
then you can change the same via "Right Click My 
Computer"-->"Manage"-> Users.. 


note that if you change it here, you also need to change it in the 
postgres service descriptor, in Control Panel->Administration 
Tools->Services



when you initially connect to postgres wtih psql or pgadmin-III, specify 
the user as `postgres` and then once connected,


CREATE USER yourname WITH PASSWORD 'somepass' createdb createrole;

and this will create a SQL account for you with that sql password, and 
give this user permission to create databases and roles (users).




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password

[Roedy Green]

On Sun, 20 Feb 2011 21:44:22 -0800, pie...@hogranch.com (John R
Pierce) wrote, quoted or indirectly quoted someone who said :

>when you initially connect to postgres wtih psql or pgadmin-III, specify 
>the user as `postgres` and then once connected,

It would not let me in even once.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password

[Roedy Green]

On Mon, 21 Feb 2011 10:45:14 +0530, sachin.srivast...@enterprisedb.com
(Sachin Srivastava) wrote, quoted or indirectly quoted someone who
said :

>Hello,
>
>Installation of postgresql requires you to enter a password for the user 
>'postgres'.
>
> i) If the user 'postgres' is not there, it will create it and set the 
> password to whatever you have provided,
> ii) If the user 'postgres' is already existing, then you have to give its 
> password to move further in the installation.
>
>You can use any account other that 'postgres' by giving CLI option 
>'---serviceaccount '. See --help for more details.
>
>In case you dont remember the password you set for user 'postgres' then you 
>can change the same via "Right Click My Computer"-->"Manage"-> Users.. 
>
>You said it rejects the password.  When ? 
>
>And windows user are most welcome here.
>
>
>On Feb 21, 2011, at 7:40 AM, Roedy Green wrote:
>
>> I gave Postgre a password during install.  However, it always rejects
>> it. I tried uninstalling, deleting all files, and reinstalling. Same
>> thing.  It complains about user "roedy" (my windows id). It seems to
>> me the default user is supposed to be postgres not Roedy.  Perhaps
>> that is the source of the problem. I can't find anything relevant in
>> the docs.
>> 
>> The docs talk about installing on Unix by compiling C source.  I have
>> Windows 7 64 bit. I get the feeling Windows users are unwelcome.
>> -- 
>> Roedy Green Canadian Mind Products
>> http://mindprod.com
>> Refactor early. If you procrastinate, you will have
>> even more code to adjust based on the faulty design.
>> .
>> 
>> 
>> -- 
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general

This did not help.  However, I have got it going.  Part of my problem
came from expecting it to work identically to MySQL.

I have posted my notes at
http://mindprod.com/jgloss/postgresql.html#GOTCHAS

The key was setting up ENV parms to get it to default to postgres as
the user id.  It was defaulting to roedy, my windows id.  I later
discovered I could force it to use postgres with the -U option. At
first this did not appear to work.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password?

[Andreas Wenk]

Ms swati chande schrieb:

Hi
 
When I write the following commands at the prompt,


 >createuser -S -d -R user1
 > createdb sample

I am asked to enter a password. I have not set any password anywhere. 
Which password is it asking for?

Please help.
I have built from source on Windows XP.

Thanks is advance,

Regards
Swati

Hi Swati,

what are the setting of your pg_hba.conf? I assume that there is a entry like 
this:

# TYPE  DATABASEUSERCIDR-ADDRESS  METHOD

# "local" is for Unix domain socket connections only
local   all all   password


That means that the password you are asked is the password of the standard user for your 
cluster - commonly postgres.


Cheers

Andy


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password?

[Andreas Wenk]

Andreas Wenk schrieb:

Ms swati chande schrieb:

Hi
 
When I write the following commands at the prompt,


 >createuser -S -d -R user1
 > createdb sample

I am asked to enter a password. I have not set any password anywhere. 
Which password is it asking for?

Please help.
I have built from source on Windows XP.

Thanks is advance,

Regards
Swati

Hi Swati,

what are the setting of your pg_hba.conf? I assume that there is a entry 
like this:


# TYPE  DATABASEUSERCIDR-ADDRESS  METHOD

# "local" is for Unix domain socket connections only
local   all all   password


That means that the password you are asked is the password of the 
standard user for your cluster - commonly postgres.


Cheers

Andy


*argh* - more detailed to avoid confusion. The auth method 'password' in pg_hba.conf 
means, that you will be asked for a password for the user you try to create a db with. If 
no user is given (with createdb -U [username]), this user is postgres ...


see also createdb --help for options ...

Cheers

Andy

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Re: [GENERAL] Password?]

[Andreas Wenk]

Serge Fonville schrieb:

*argh* - more detailed to avoid confusion. The auth method 'password' in
pg_hba.conf means, that you will be asked for a password for the user you
try to create a db with. If no user is given (with createdb -U [username]),
this user is postgres ...


Wasn't it that it uses the currently logged on user is used if no user
is specified?


correct - so this will be postgres because other users are not allowed to use 
these
programs ...

/var/lib/postgresql/8.4/bin$ ./createdb test -p 5433
createdb: could not connect to database postgres: FATAL:  role "duke" does not 
exist

$ sudo su postgres
postg...@duke-linux:~/8.4/bin$ ./createdb test -p 5433
postg...@duke-linux:~/8.4/bin$

auth method in pg_hba.conf is trust in this case.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password?

[Abbas]

On Wed, Jul 8, 2009 at 3:22 PM, Andreas Wenk  wrote:

> Andreas Wenk schrieb:
>
>> Ms swati chande schrieb:
>>
>>> Hi
>>>  When I write the following commands at the prompt,
>>>
>>>  >createuser -S -d -R user1
>>>  > createdb sample
>>>
>>> I am asked to enter a password. I have not set any password anywhere.
>>> Which password is it asking for?
>>> Please help.
>>> I have built from source on Windows XP.
>>>
>>> Thanks is advance,
>>>
>>> Regards
>>> Swati
>>>
>> Hi Swati,
>>
>> what are the setting of your pg_hba.conf? I assume that there is a entry
>> like this:
>>
>> # TYPE  DATABASEUSERCIDR-ADDRESS  METHOD
>>
>> # "local" is for Unix domain socket connections only
>> local   all all   password
>>
>>
>> That means that the password you are asked is the password of the standard
>> user for your cluster - commonly postgres.
>>
>> Cheers
>>
>> Andy
>>
>
> *argh* - more detailed to avoid confusion. The auth method 'password' in
> pg_hba.conf means, that you will be asked for a password for the user you
> try to create a db with. If no user is given (with createdb -U [username]),
> this user is postgres ...
>
> see also createdb --help for options ...
>
>
> Cheers
>
> Andy
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

  If you don't need the password authentication you have to edit the
pg_conf file and replace "password" with "trust", after this reload the
cluster. It won't prompt you for password.

Thanks,
Abbas.

Re: [GENERAL] Password?

[Andreas Wenk]

Ms swati chande schrieb:

--- On *Wed, 7/8/09, Andreas Wenk //* wrote:


From: Andreas Wenk 
Subject: Re: [GENERAL] Password?
To: "Ms swati chande" , "PG-General Mailing List"

Date: Wednesday, July 8, 2009, 3:47 PM

Ms swati chande schrieb:
 > Thanks Andy,
 >  I am working on Windows XP. Have built from source using Visual
Studio 2005.
 >  I have made a change in pg_hba.conf to include the ipconfig of
my system.
 > # TYPE  DATABASEUSERCIDR-ADDRESS  METHOD
 >  *hostall all   trust*
 >  # IPv4 local connections:
 > hostall all 127.0.0.1/32  trust
 > # IPv6 local connections:
 > #hostall all ::1/128   trust
 >
 >  This was to take care of the following problem:
 >  LOG: could not bind IPv4 socket: Address already in use
 > HINT: Is another postmaster already running on port 5432? If not,
wait a few seconds and retry.
 > WARNING: could not create listen socket for "*"
 > FATAL: could not create any TCP/IP sockets
 >  For this I changed the listen_addresses to my current ip. and
made the same change in pg_hba.conf.
 >  Thanks
 >  Regards
 > Swati
 > 


So does it work now ? Why is there a * sign before host? This seems
to be incorrect ...

P.S.: dont' forget to reply also to the mailinglist (reply to all)



>
> No its still not working.
> The * doesn't exist in pg_hba. It was probably in the mail as I had
> formatted that line to be 'bold'.

ah ok ..

Actually it should work if you set listen_addresses to '*' in postgresql.conf. Did you 
change anything else in postgresql.conf or pg_hba.conf?


I am not too experienced with Windows so maybe someone with more knowledge is able to find 
the trick (I installed 8.4 once with the one click installer ...no problems at all). But 
as far as I understand something is wrong with:


> WARNING: could not create listen socket for "*"
> FATAL: could not create any TCP/IP sockets

I understand correct, that you fixed this? Then it should work as I mentioned 
earlier ...

Cheers Andy

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password?

[Andreas Wenk]

Ms swati chande schrieb:

Thanks Andy,
 
I am working on Windows XP. Have built from source using Visual Studio 2005.
 
I have made a change in pg_hba.conf to include the ipconfig of my system. 


# TYPE  DATABASEUSERCIDR-ADDRESS  METHOD
 
*hostall all   trust*
 
# IPv4 local connections:

hostall all 127.0.0.1/32  trust
# IPv6 local connections:
#hostall all ::1/128   trust

 
This was to take care of the following problem:
 
LOG: could not bind IPv4 socket: Address already in use
HINT: Is another postmaster already running on port 5432? If not, wait a 
few seconds and retry.

WARNING: could not create listen socket for "*"
FATAL: could not create any TCP/IP sockets
 
For this I changed the listen_addresses to my current ip. and made the 
same change in pg_hba.conf.
 
Thanks
 
Regards

Swati
 


So does it work now ? Why is there a * sign before host? This seems to be 
incorrect ...

P.S.: dont' forget to reply also to the mailinglist (reply to all)

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password?

[Ms swati chande]

>ah ok ..

>Actually it should work if you set listen_addresses to '*' in postgresql.conf. 
>Did you >change anything else in postgresql.conf or pg_hba.conf?

>I am not too experienced with Windows so maybe someone with more knowledge is 
>able >to find the trick (I installed 8.4 once with the one click installer 
>...no problems at all). But >as far as I understand something is wrong with:

>> WARNING: could not create listen socket for "*"
>>FATAL: could not create any TCP/IP sockets

>I understand correct, that you fixed this? Then it should work as I mentioned 
>earlier ...

Cheers Andy

 
 
Ok. Will check the '*' part of it and then get back.
Infact it was to move ahead with it that I changes the listen addresses in 
postgresql.conf.
But will take another look into it.
Thanks,
 
Regards
Swati




  

Re: [GENERAL] Password?

[Abbas]

On Wed, Jul 8, 2009 at 4:12 PM, Andreas Wenk  wrote:

> Ms swati chande schrieb:
>
>> --- On *Wed, 7/8/09, Andreas Wenk //*
>> wrote:
>>
>>
>>    From: Andreas Wenk 
>>Subject: Re: [GENERAL] Password?
>>To: "Ms swati chande" , "PG-General Mailing List"
>>
>>Date: Wednesday, July 8, 2009, 3:47 PM
>>
>>Ms swati chande schrieb:
>> > Thanks Andy,
>> >  I am working on Windows XP. Have built from source using Visual
>>Studio 2005.
>> >  I have made a change in pg_hba.conf to include the ipconfig of
>>my system.
>> > # TYPE  DATABASEUSERCIDR-ADDRESS  METHOD
>> >  *hostall all   trust*
>> >  # IPv4 local connections:
>> > hostall all 127.0.0.1/32  trust
>> > # IPv6 local connections:
>> > #hostall all ::1/128   trust
>>
>
Yes, the * sign should removed and have to mention listen_addresses = ' * '
in Postgresql.conf file.


>
>> >
>> >  This was to take care of the following problem:
>> >  LOG: could not bind IPv4 socket: Address already in use
>> > HINT: Is another postmaster already running on port 5432? If not,
>>wait a few seconds and retry.
>> > WARNING: could not create listen socket for "*"
>> > FATAL: could not create any TCP/IP sockets
>> >  For this I changed the listen_addresses to my current ip. and
>>made the same change in pg_hba.conf.
>> >  Thanks
>> >  Regards
>> > Swati
>> >
>>So does it work now ? Why is there a * sign before host? This seems
>>to be incorrect ...
>>
>>P.S.: dont' forget to reply also to the mailinglist (reply to all)
>>
>>
>>  >
> > No its still not working.
> > The * doesn't exist in pg_hba. It was probably in the mail as I had
> > formatted that line to be 'bold'.
>
> ah ok ..
>
> Actually it should work if you set listen_addresses to '*' in
> postgresql.conf. Did you change anything else in postgresql.conf or
> pg_hba.conf?
>
> I am not too experienced with Windows so maybe someone with more knowledge
> is able to find the trick (I installed 8.4 once with the one click installer
> ...no problems at all). But as far as I understand something is wrong with:
>
> > WARNING: could not create listen socket for "*"
> > FATAL: could not create any TCP/IP sockets
>
> I understand correct, that you fixed this? Then it should work as I
> mentioned earlier ...
>
> Cheers Andy
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [GENERAL] Password?

[Ms swati chande]

Hi,
 
I started everything again from scratch.
1. Created a new user("Swati"), with limited/ restricted rights.
    Ensured that no password is set anywhere.
 
2. Ran initdb from the new user.
    c:\postgresql\bin>initdb -D c:\postgresql\data2
   It displayed the DEBUG: start transaction and commit transaction states 
etc.
   and ended with DEBUG: exit(0)
   A warning with the following statement was also displayed:
     WARNING: enabling "trust" authentication foe local connections
     you can change this by editing "pg_hba.conf" or by initdb -A.
 
3. After this I executed pg_ctl:
     c:\postgresql\bin>pg_ctl -D c:\postgresql\data2 -l logfile start
 got the the message:server starting
 and the logfile contained the following:
 LOG:  could not bind IPv4 socket: No error
 HINT:  Is another postmaster already running on port 5432? If 
not,
 wait a few seconds and retry.
     WARNING:  could not create listen socket for "localhost"
     FATAL:  could not create any TCP/IP sockets
     LOG:  could not bind IPv4 socket: No error
 HINT:  Is another postmaster already running on port 5432? If 
not, wait
     a few seconds and retry.
 WARNING:  could not create listen socket for "localhost"
     FATAL:  could not create any TCP/IP sockets
 
4. To take care of the above issues,
     Made the following change in the postgresql.conf file:
 listen_addresses = 'xxx.xxx.x.x' (my current ip)
     and in pg_hba:
     host all all 'xxx.xxx.x.x' trust
 
5.Then issued
 c:\postgresql\bin>pg_ctl -D c:\postgresql\data2 -l logfile start
   again.
   Now got the following in logfile:
     LOG: database system was shut down at 2009-07-08 22:34:50
     LOG: database system is ready to accept connections
     LOG:  autovacuum launcher started
 
6.Opened another command window.
   Now when I write in the new window (or even in the same),
     c:\postgresql\bin>createdb demo
   OR
     c:\postgresql\bin>createuser -S -d -R svc
   I am prompted for password, I don't know what to enter here. 
 
I think I am making some mistake in pg_hba.conf. Can't make out.
Must be some brainless blunder some where.
 
Thanks a ton for sparing your time and bearing with me.
 
Please guide.
 
Regards
Swati



  

Re: [GENERAL] Password?

[Andreas Wenk]

Ms swati chande schrieb:

Hi,
 
I started everything again from scratch.

1. Created a new user("Swati"), with limited/ restricted rights.
Ensured that no password is set anywhere.
 
2. Ran initdb from the new user.

c:\postgresql\bin>initdb -D c:\postgresql\data2
   It displayed the DEBUG: start transaction and commit
transaction states etc.
   and ended with DEBUG: exit(0)
   A warning with the following statement was also displayed:
 WARNING: enabling "trust" authentication foe local
connections
 you can change this by editing "pg_hba.conf" or by
initdb -A.
 
3. After this I executed pg_ctl:

 c:\postgresql\bin>pg_ctl -D c:\postgresql\data2 -l
logfile start
 got the the message:server starting
 and the logfile contained the following:
 LOG:  could not bind IPv4 socket: No error
 HINT:  Is another postmaster already running on
port 5432? If not,
 wait a few seconds and retry.
 WARNING:  could not create listen socket for
"localhost"
 FATAL:  could not create any TCP/IP sockets
 LOG:  could not bind IPv4 socket: No error
 HINT:  Is another postmaster already running on
port 5432? If not, wait
 a few seconds and retry.
 WARNING:  could not create listen socket for
"localhost"
 FATAL:  could not create any TCP/IP sockets
 
4. To take care of the above issues,

 Made the following change in the postgresql.conf file:
 listen_addresses = 'xxx.xxx.x.x' (my current ip)
 and in pg_hba:
 host all all 'xxx.xxx.x.x' trust
 
5.Then issued

 c:\postgresql\bin>pg_ctl -D c:\postgresql\data2 -l logfile
start
   again.
   Now got the following in logfile:
 LOG: database system was shut down at 2009-07-08
22:34:50
 LOG: database system is ready to accept connections
 LOG:  autovacuum launcher started
 
6.Opened another command window.

   Now when I write in the new window (or even in the same),
 c:\postgresql\bin>createdb demo
   OR
 c:\postgresql\bin>createuser -S -d -R svc
   I am prompted for password, I don't know what to enter here.
 
I think I am making some mistake in pg_hba.conf. Can't make out.

Must be some brainless blunder some where.
 
Thanks a ton for sparing your time and bearing with me.
 
Please guide.
 
Regards

Swati


Swati, sorry to say - but I got no solution as I cannot try to simulate 
this. I do not have a Windows machine ... hopefully someone else can help.


One thing anyway ...  Step 4. seems to be correct. Actually, is there a 
user postgres on your system? Why not give postgres then a password (in 
the windows user administration) and use


c:\postgresql\bin>createuser -U postgres -S -d -R svc

But this is really vague ...

Cheers

Andy

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password?

[John R Pierce]

Ms swati chande wrote:



 Made the following change in the postgresql.conf file:
 listen_addresses = 'xxx.xxx.x.x' (my current ip)
 and in pg_hba:
 host all all 'xxx.xxx.x.x' trust
 
...

6.Opened another command window.
   Now when I write in the new window (or even in the same),
 c:\postgresql\bin>createdb demo
   OR
 c:\postgresql\bin>createuser -S -d -R svc
   I am prompted for password, I don't know what to enter here.
 



try ...
   createuser -h xxx.xxx.x.x -S -d -R svc

by default, its connecting to localhost (127.0.0.1) rather than your IP.

(note this behavior is different than on Unix/Linux type systems, where 
by default it connects to a 'unix domain socket', which doesn't exist on 
MS Windows).





If you only want to connect to this database from the same computer, I'd 
suggest using 127.0.0.1/localhost rather than xxx.xxx.x.x in both the 
listen_address and pg_hba...




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password?

[Adrian Klaver]

On Wednesday 08 July 2009 11:48:08 am Ms swati chande wrote:
> Hi,
>  
> I started everything again from scratch.
> 1. Created a new user("Swati"), with limited/ restricted rights.
>     Ensured that no password is set anywhere.

How limited? Can this user do administrative tasks, i.e create database,create 
user?

>  
> 2. Ran initdb from the new user.
>     c:\postgresql\bin>initdb -D c:\postgresql\data2
>    It displayed the DEBUG: start transaction and commit transaction
> states etc. and ended with DEBUG: exit(0)
>    A warning with the following statement was also displayed:
>      WARNING: enabling "trust" authentication foe local connections
>      you can change this by editing "pg_hba.conf" or by initdb -A.
>  
> 3. After this I executed pg_ctl:
>      c:\postgresql\bin>pg_ctl -D c:\postgresql\data2 -l logfile
> start got the the message:server starting
>  and the logfile contained the following:
>  LOG:  could not bind IPv4 socket: No error
>  HINT:  Is another postmaster already running on port 5432?
> If not, wait a few seconds and retry.
>      WARNING:  could not create listen socket for "localhost"
>      FATAL:  could not create any TCP/IP sockets
>      LOG:  could not bind IPv4 socket: No error
>  HINT:  Is another postmaster already running on port 5432?
> If not, wait a few seconds and retry.
>  WARNING:  could not create listen socket for "localhost"
>      FATAL:  could not create any TCP/IP sockets
>  
> 4. To take care of the above issues,
>      Made the following change in the postgresql.conf file:
>  listen_addresses = 'xxx.xxx.x.x' (my current ip)
>      and in pg_hba:
>      host all all 'xxx.xxx.x.x' trust

Can you show the complete pg_hba.conf file? Or to put it another way is the 
above line the only uncommented line in the file?

>  
> 5.Then issued
>  c:\postgresql\bin>pg_ctl -D c:\postgresql\data2 -l logfile start
>    again.
>    Now got the following in logfile:
>      LOG: database system was shut down at 2009-07-08 22:34:50
>      LOG: database system is ready to accept connections
>      LOG:  autovacuum launcher started
>  
> 6.Opened another command window.
>    Now when I write in the new window (or even in the same),
>      c:\postgresql\bin>createdb demo
>    OR
>      c:\postgresql\bin>createuser -S -d -R svc
>    I am prompted for password, I don't know what to enter here.

Are you running this as 'Swati' user?

>  
> I think I am making some mistake in pg_hba.conf. Can't make out.
> Must be some brainless blunder some where.
>  
> Thanks a ton for sparing your time and bearing with me.
>  
> Please guide.
>  
> Regards
> Swati



-- 
Adrian Klaver
akla...@comcast.net

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] [Password?]

[Ms swati chande]

Hi,
 
Thank you all for your kind responses.
 
Things however aren't falling in place. 
 
Will take a short break, rework, and get back.
Probably, with a new problem!
 
Thanks again,
Regards
Swati


  

Re: [GENERAL] Password Policy

[Ezequias Rodrigues da Rocha]

Hi list (my first post),

Is there any password polity that postgresql implement ?

It is possible to put a set all no administrators passwords to = '123456'
from times and times ?

Has anyone implement a dinamic password autentication (the password
changes according the date/month etc of a day ) ?



Is there any function to encript, decript plain text in PostgreSQL  and if
it is aplicable ?

Regards ...

Ezequias

Re: [GENERAL] password cookie

[Andrew Sullivan]

On Wed, Oct 25, 2006 at 03:49:54PM +0200, Willy-Bas Loos wrote:
> So as a temporary compromise, we decided to store the username and password
> in a cookie on the client PC, which is of course a serious weakness.
> 
> Can anyone give me some advise on how to do this a better way, without
> consuming too much time, or is this the best thing to do in such a
> situation?

The usual workaround I'm familiar with is to set a hash of some sort
that is the user, password, and some salt.  Then you authenticate
against that hash in your application, so that you never actually
send these values, nor store them anywhere except the database.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] password cookie

[Willy-Bas Loos]

I think that´s not exactly what i´m looking for.Just to make sure that i understand what you´re proposing (please correct me if i´m wrong):I´ll write a function that will create a hash of username, password and, say 'now'::timestamp and store it in a cookie and in a separate table somewhere on the cluster, if authentication is succesfull.
Then, upon every need for authorisation, the frontend will log into the database as a highly priviliged user (or allready be logged in), and compare the hashed values. If they are equal, it will allow certain actions.
After some time, i´ll trigger to delete the hash from the database.I could still store the user name on the back end, and retreive it with the provided hash, so that i know what actions to allow. I would then fake postgreSQL´s authentication by querying the rights and roles for this user.
The problem is that the frontend would in fact have to be some major user that regulates all authorisation, and the password for it would have to be stored on the webserver.What i am looking for is this:
Every time the user / frontend asks for certain data (or actions), he will or will not receive those, because of the rights granted to him. These granted rights and roles will be determined by the regular postgres functionality (and some views).
The frontend does have a low priviliged username and password stored in it, just to access the web-content.WBLOn 10/25/06, Andrew Sullivan
 <[EMAIL PROTECTED]> wrote:
The usual workaround I'm familiar with is to set a hash of some sort
that is the user, password, and some salt.  Then you authenticateagainst that hash in your application, so that you never actuallysend these values, nor store them anywhere except the database.

Re: [GENERAL] password cookie

[Andrew Sullivan]

On Thu, Oct 26, 2006 at 12:27:49AM +0200, Willy-Bas Loos wrote:
> or will not receive those, because of the rights granted to him. These
> granted rights and roles will be determined by the regular postgres
> functionality (and some views).

Ah, that's a different matter.  My suggestion is "don't do that". 
I tried to do it once, years ago, and regretted it deeply.  Of
course, my code was awful, and yours might be better.  But in my
view, that's a security problem just waiting to happen.  You're
better off to have one user in your application that does the
authentication for you.  You can use Kerberos or something to
authenticate it; much easier to lock down one such user carefully,
that comes only from boxes under your control, than to secure many
users' accounts.

If you want to do it this way, I sure wouldn't use cookies to store
the password.  I think you're asking for a compromise that way.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] password cookie

[Willy-Bas Loos]

> My suggestion is "don't do that".> I tried to do it once, years ago, and regretted it deeply.Do you mean "don´t try to fake postgres´ authorisation" (which i don´t want to),or "don´t set up your webservice so that users will recieve data according to their own rights in the database, where each frontend user equals a database user" (which i do want to)?
WBL

Re: [GENERAL] password cookie

[Willy-Bas Loos]

I just learned to read, sorry.You mean not to do the second thing, which i do want to do (where each frontend user equals a database user).Thank you for your advise.I´m not sure if i can get around it, but i´ll use extra caution anayway.
WBLOn 10/27/06, Willy-Bas Loos <[EMAIL PROTECTED]> wrote:
> My suggestion is "don't do that".> I tried to do it once, years ago, and regretted it deeply.Do you mean "don´t try to fake postgres´ authorisation" (which i don´t want to),
or "don´t set up your webservice so that users will recieve data according to their own rights in the database, where each frontend user equals a database user" (which i do want to)?
WBL

Re: [GENERAL] password reset

[Bill Moran]

On Tue, 23 May 2006 17:03:14 +0200
"venu Vempati" <[EMAIL PROTECTED]> wrote:

> Hi group,
> thanks for your previous response about the DB storage in postgres.
> 
> now, I have a question for a password related issue.As you can see I have
> problems with my pwd.
> Either I forgot or misconfigured while installing the DB.I have loged in to
> XP as the user "vgopal" and it's the Admin account for XP.
> 
> C:\Program Files\PostgreSQL\8.1\bin>psql
> Password:
> psql: FATAL:  password authentication failed for user "vgopal"
> 
> what are the options do I have?
> 1.reset pwd.! how?
> 2.I can't even create another user/role
> (createuser: could not connect to database postgres: FATAL:  password
> authentication failed for user "vgopal")

You can edit the pg_hba.conf file in PostgreSQL's data directory to change
authentication to "trust" for the local machine.  They'll you'll be able to
log in without a password and you can reset your password, then switch
the pg_hba.conf setting back.

Note that you'll need to restart PostgreSQL for changes to pg_hba.conf to
take effect.

-- 
Bill Moran
Collaborative Fusion Inc.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] password reset

[Jim C. Nasby]

On Tue, May 23, 2006 at 05:03:14PM +0200, venu Vempati wrote:
> Hi group,
> thanks for your previous response about the DB storage in postgres.
> 
> now, I have a question for a password related issue.As you can see I have
> problems with my pwd.
> Either I forgot or misconfigured while installing the DB.I have loged in to
> XP as the user "vgopal" and it's the Admin account for XP.
> 
> C:\Program Files\PostgreSQL\8.1\bin>psql
> Password:
> psql: FATAL:  password authentication failed for user "vgopal"

Easiest thing would be to edit pg_hba.conf and set localhost access to
trust:

# "local" is for Unix domain socket connections only
local   all all   trust
# IPv4 local connections:
hostall all 127.0.0.1/32  trust
# IPv6 local connections:
hostall all ::1/128   trust
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] password management

[Craig Ringer]

On 7/05/2010 2:31 AM, akp geek wrote:

Dear all -

I am writing function to handle the passwords. Currently
the crypt is being used to store the password in the database. what I
need to do is, when the user wants to change the password, I need to
check if that password is not being used before up to 5 times, If not
then then records should be inserted to the database.

   The problem where i am running into, when I capture the
password that user entered, I can't compare to the one in database ,
because each time the function crypt gives different one. Is there any
way that I can achieve this?


Extract the salt from each stored password and re-encrypt the new 
password with the same salt when comparing it to the old one.


eg:


craig=> create table password_history ( password text not null );
CREATE TABLE
craig=> insert into password_history(password) values ( crypt('fred', 
gen_salt('md5')) );

INSERT 0 1
craig=> insert into password_history(password) values ( crypt('bob', 
gen_salt('md5')) );

INSERT 0 1
craig=> insert into password_history(password) values ( 
crypt('smeghead', gen_salt('md5')) );

INSERT 0 1
craig=> create or replace function extract_salt(text) returns text as $$
craig$> select (regexp_matches($1, E'^(\\$[^\\$]+\\$[^\\$]+)\\$'))[1];
craig$> $$ language sql immutable;
CREATE FUNCTION
craig=> select extract_salt(password), password from password_history;
 extract_salt |  password
--+
 $1$p3AMpr5s  | $1$p3AMpr5s$BtNTSXwIJbHrdnJEZ4NFg.
 $1$FKySMIXg  | $1$FKySMIXg$xFM5osjqclTuaJIUiGvU3.
 $1$MUwd2dGt  | $1$MUwd2dGt$w06IEIvJ1lROXw7WGb3dw.
(3 rows)

craig=> select exists (select 1 from password_history where 
crypt('fred', extract_salt(password)) = password);

 ?column?
--
 t
(1 row)

craig=> select exists (select 1 from password_history where crypt('bob', 
extract_salt(password)) = password);

 ?column?
--
 t
(1 row)

craig=> select exists (select 1 from password_history where 
crypt('nosuch', extract_salt(password)) = password);

 ?column?
--
 f
(1 row)



Make sure to generate a new salt value if you accept the password and 
want to store it, though.



( Perhaps pgcrypto needs a function to extract the salt? )


--
Craig Ringer

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password management

[Craig Ringer]

On 7/05/2010 12:01 PM, Craig Ringer wrote:


craig=> create or replace function extract_salt(text) returns text as $$
craig$> select (regexp_matches($1, E'^(\\$[^\\$]+\\$[^\\$]+)\\$'))[1];
craig$> $$ language sql immutable;


Upon re-reading the pgcrypto documentation I see that this is unnecessary.

Just pass the password hash as the salt. Pgcrypto will extract the salt 
part of the hash its self. (otherwise, how could you check passwords?)


So - just as if you were testing authentication, crypt the user's new 
password plaintext against each of the old password hashes using the old 
password hash as salt, and see if the output hash is the same as the old 
password hash. If it is, they've re-used the password.


--
Craig Ringer

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password management

[Christophe Dore]

Hi

 

IMHO, you should never store password in clear

 

If you store the last 5 crypted passwords, then you can make it  comparing the 
new password, crypted, to those 5 strings.

 

Regards

 

-- 

Christophe Doré 
Implementation Product Manager 

3 rue Marcel Allegot 
92190 Meudon, France 
+33 1 46 90 21 00 office 
+33 6 1379 2910 mobile 
CAST, Leader in Automated Application Intelligence 
Achieve Insight. Deliver Excellence. 

www.castsoftware.com   | Gain visibility into 
application quality to proactively manage risk and improve team performance.

From: akp geek [mailto:akpg...@gmail.com] 
Sent: jeudi 6 mai 2010 20:31
To: pgsql-general
Subject: password management

 

Dear all -

 

   I am writing function to handle the passwords. Currently the 
crypt is being used to store the password in the database. what I need to do 
is, when the user wants to change the password, I need to check if that 
password is not being used before up to 5 times, If not then then records 
should be inserted to the database.

 

  The problem where i am running into, when I capture the password 
that user entered, I can't compare to the one in database , because each time 
the function crypt gives different one. Is there any way that I can achieve 
this?

 

  Appreciate your help

 

Regards

Re: [GENERAL] Password issue

[Ashesh Vashi]

'-W' option is there to prompt the password.

Use PGPASSWORD environment variable.
http://www.postgresql.org/docs/8.3/static/libpq-envars.html

*createdb creates a PostgreSQL database.*
*
*
*Usage:*
*  createdb [OPTION]... [DBNAME] [DESCRIPTION]*
*
*
*Options:*
*  -D, --tablespace=TABLESPACE  default tablespace for the database*
*  -e, --echo   show the commands being sent to the server*
*  -E, --encoding=ENCODING  encoding for the database*
*  -l, --locale=LOCALE  locale settings for the database*
*  --lc-collate=LOCALE  LC_COLLATE setting for the database*
*  --lc-ctype=LOCALELC_CTYPE setting for the database*
*  -O, --owner=OWNERdatabase user to own the new database*
*  -T, --template=TEMPLATE  template database to copy*
*  --help   show this help, then exit*
*  --versionoutput version information, then exit*
*
*
*Connection options:*
*  -h, --host=HOSTNAME  database server host or socket directory*
*  -p, --port=PORT  database server port*
*  -U, --username=USERNAME  user name to connect as*
*  -w, --no-passwordnever prompt for password*
*  -W, --password   force password prompt*

On Thu, May 19, 2011 at 8:23 PM, Mahmoud  wrote:

> Hi all
> I am trying to create a database by passing arguments to createdb.exe but
> createdb always asks me about the password although I passed  -W 123 to it.
>
> How can I override password request?
>
> PS
> This my test for creating the database
> createdb.exe -U postgres -W 123 -O admin -e test
>
> Cheers.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 
--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company



*http://www.linkedin.com/in/asheshvashi*

Re: [GENERAL] Password issue

[hubert depesz lubaczewski]

On Thu, May 19, 2011 at 05:53:11PM +0300, Mahmoud wrote:
> Hi all
> I am trying to create a database by passing arguments to
> createdb.exe but createdb always asks me about the password although
> I passed  -W 123 to it.

please check docs for createdb
http://www.postgresql.org/docs/current/interactive/app-createdb.html

-W is not used to provide password at command line.

for providing password check
http://www.postgresql.org/docs/current/interactive/libpq-envars.html
and/or
http://www.postgresql.org/docs/current/interactive/libpq-pgpass.html

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
 http://depesz.com/

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password issue

[Albe Laurenz]

Mahmoud wrote:
> I am trying to create a database by passing arguments to createdb.exe
> but createdb always asks me about the password although I passed  -W 123
> to it.
>
> How can I override password request?
>
> PS
> This my test for creating the database
> createdb.exe -U postgres -W 123 -O admin -e test

As has been mentioned, -W takes no arguments and prompts you for a password.

If you want a password, but don't want the prompt (e.g. because you are
writing a script), you could:

- Not use -W, then the superuser will have no password initially.
- Start the server.
- Using "trust" authentication, connect to a database.
- Issue "ALTER ROLE ... PASSWORD '...'" to set a password.

Yours,
Laurenz Albe



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [Re: [GENERAL] Password?]

[Ms swati chande]

Yes,
Its the currently logged on user.


--- On Wed, 7/8/09, Andreas Wenk  wrote:


From: Andreas Wenk 
Subject: [Re: [GENERAL] Password?]
To: "PG-General Mailing List" 
Date: Wednesday, July 8, 2009, 3:54 PM


Serge Fonville schrieb:
>> *argh* - more detailed to avoid confusion. The auth method 'password' in
>> pg_hba.conf means, that you will be asked for a password for the user you
>> try to create a db with. If no user is given (with createdb -U [username]),
>> this user is postgres ...
> 
> Wasn't it that it uses the currently logged on user is used if no user
> is specified?

correct - so this will be postgres because other users are not allowed to use 
these
programs ...

/var/lib/postgresql/8.4/bin$ ./createdb test -p 5433
createdb: could not connect to database postgres: FATAL:  role "duke" does not 
exist

$ sudo su postgres
postg...@duke-linux:~/8.4/bin$ ./createdb test -p 5433
postg...@duke-linux:~/8.4/bin$

auth method in pg_hba.conf is trust in this case.

-- Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



  

Re: [GENERAL] password authentication

[Oliver Elphick]

Phuong Ma wrote:
  >Hi, 
  >
  >  I was wondering what the different methods of creating a password
  >accomplish because I created a password for a test user using the
  >command WITH PASSWORD.  I tried testing to see if I could log on without
  >a password, and it worked.  Is there anything else I would need to do to
  >activate the password authentication?  Does the pg_hba.conf file have
  >anything to do with this?  If it does, and I only want to create a
  >password for this one user, would I specify it in the pg_hba.conf file?
 
Use pg_hba.conf to turn on password checking.  Checking is done if
the connection method, database (and connection source for TCP/IP) match
a line in pg_hba.conf that requires it.

You cannot turn on checking per _user_.  It's all users or none.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "For this reason I also suffer these things,  
  but I am not ashamed; for I know whom I have  
  believed, and am persuaded that He is able to keep 
  that which I have committed unto him until that day."
 II Timothy 1:12 



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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [GENERAL] password help

[Craig Ringer]

On 07/30/2012 02:30 AM, Guillermo Echevarria Quintana-Gurt wrote:


Hi, I just uninstalled version 8.4 and tried installing version 9.1 in 
my computer (my system is Windows 7). The issue Im facing was that 
when I clicked run to install the new version one of the steps was 
requiring me the following:
"please provide a password for the database superuser (postgres) and 
service account (postgress). If the service account already exists in 
windows, you must enter the current password for the account. If the 
account doesnt exist, it will be created when you click "next""


As per the blog you linked to, open an administrator command prompt by 
right-clicking on the command prompt entry it in the start menu and 
choosing "Run as administrator", then in the command prompt run:


   net user postgres *

and enter a new password when prompted.

If you can't find the command prompt in the start menu, just type 
"command" into the Start menu search box and it will appear in the list.


Alternately, try completely uninstalling all PostgreSQL versions, then 
using the system management console to delete the "postgres" user. You 
cannot do this via the "users" control panel, it must be done via the 
usermgmt mmc snapin, which you can find called User Management within 
Administrative Tools in the control panel.


It seems the 9.2 installers will use a different setup that won't 
require a service password anymore. (Thanks Dave!).


--
Craig Ringer

Re: [GENERAL] password help

[Craig Ringer]

Please don't reply directly to me, reply via the mailing list (use 
"Reply all").


On 07/30/2012 01:35 PM, Guillermo Echevarria Quintana-Gurt wrote:

Hi Craig, I really appreciate your answer. My situation is the one I described 
you in the first email. I guess i should've add that i really have no clue 
about how to use/run or do anything related with postgresql, i downloaded it 
because i was told I had to have it in order for a software i was going to use 
to work (holdem manager). I installed it and things worked fine, dont remember 
anytime doing anything with or to postgres. My problem comes now that I 
upgraded to holdem manager 2 and cant get to open it, i was told that it COULD 
be related to something to postgres and i could try uninstalling and 
reinstalling it again to see if things worked then. I tried that but as told 
encountered the password problem.
This is a Holdem Manager issue. They've done a silent installation of 
PostgreSQL, and their upgrade tool clearly doesn't do its job right.


Please contact their technical support for assistance.

--
Craig Ringer

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password help

[Craig Ringer]

On 07/30/2012 02:00 PM, Guillermo Echevarria Quintana-Gurt wrote:
Im contacting them tomorrow for sure. My issue is that I uninstalled 
the postgresql system from my computer and now I cant get it installed 
again because of the password issue. Thats all im trying to solve, 
getting the postgresql installed again in my laptop and like 
said because of being really really clulesss im having issues with 
that and im really sorry for taking your time on helping me.

A google search for "windows 7 administrator command prompt" reveals:

http://technet.microsoft.com/en-us/library/cc947813(v=ws.10).aspx 



and

http://www.howtogeek.com/howto/windows-vista/run-a-command-as-administrator-from-the-windows-vista-run-box/

both of which explain in detail how to open a command prompt as 
administrator. It's similarly easy to find instructions on how to get to 
the administrative tools in the control panel.


The best way to be less "clueless" - as you call yourself - about 
computers is to actively learn by trying to research things when you run 
into problems. These days Google will often find the answer if you try a 
few different ways to ask the question.


Try re-reading Dave's blog post slowly. When you encounter something you 
don't understand, look it up. It will take longer that way, but you will 
learn more and most importantly you will be more able to solve your own 
problems in future.


--
Craig Ringer

Re: [GENERAL] password help

[Guillermo Echevarria Quintana-Gurt]

Im contacting them tomorrow for sure. My issue is that I uninstalled the 
postgresql system from my computer and now I cant get it installed again 
because of the password issue. Thats all im trying to solve, getting the 
postgresql installed again in my laptop and like said because of being really 
really clulesss im having issues with that and im really sorry for taking your 
time on helping me.
 > Date: Mon, 30 Jul 2012 13:49:03 +0800
> From: ring...@ringerc.id.au
> To: guie...@hotmail.com; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] password help
> 
> Please don't reply directly to me, reply via the mailing list (use 
> "Reply all").
> 
> On 07/30/2012 01:35 PM, Guillermo Echevarria Quintana-Gurt wrote:
> > Hi Craig, I really appreciate your answer. My situation is the one I 
> > described you in the first email. I guess i should've add that i really 
> > have no clue about how to use/run or do anything related with postgresql, i 
> > downloaded it because i was told I had to have it in order for a software i 
> > was going to use to work (holdem manager). I installed it and things worked 
> > fine, dont remember anytime doing anything with or to postgres. My problem 
> > comes now that I upgraded to holdem manager 2 and cant get to open it, i 
> > was told that it COULD be related to something to postgres and i could try 
> > uninstalling and reinstalling it again to see if things worked then. I 
> > tried that but as told encountered the password problem.
> This is a Holdem Manager issue. They've done a silent installation of 
> PostgreSQL, and their upgrade tool clearly doesn't do its job right.
> 
> Please contact their technical support for assistance.
> 
> --
> Craig Ringer
  

Re: [GENERAL] Password encryption method

[Martijn van Oosterhout]

On Fri, Jan 19, 2007 at 09:31:49AM +0100, Bertram Scharpf wrote:
> Hi,
> 
> looking at the source code I find out that this works:



> May I rely on this in future versions or are there more
> sophisticated ways to do it?

Umm, how much more sophisticated do you want? It's more sophicticated
than a standard UNIX password file, for example. For password
authentication the server either needs to be able to verify the
password supplied by the user, and you have the same information the
server does, so you can do it too.

Only superusers have access to pg_authid anyway, and they can already
login as anybody.

If you don't like it, don't use password authentication, there are a
number of other methods.

Have a nice day,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to 
> litigate.


signature.asc
Description: Digital signature

Re: [GENERAL] Password encryption method

[Bruno Wolff III]

On Fri, Jan 19, 2007 at 09:31:49 +0100,
  Bertram Scharpf <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> looking at the source code I find out that this works:
> 
>   sandbox=# create role joe login password 'verysecret';
>   CREATE ROLE
>   sandbox=# create function validate_user_8_1(text,text) returns boolean 
> immutable language 'sql' as $$ select 'md5'||md5($2||$1) = rolpassword from 
> pg_authid where rolname=$1; $$;
>   CREATE FUNCTION
>   sandbox=# select validate_user_8_1('joe','verysecret');
>validate_user_8_1
>   ---
>t
>   (1 Zeile)
> 
> May I rely on this in future versions or are there more
> sophisticated ways to do it?

I don't know that I would 'rely' on it, but it doesn't seem like something
that is likely to change any time soon. But I could see there being alternate
hash functions being used eventually.

It might make more sense to use your own table of users and hashed passwords
rather than postgres'. This would depend somewhat on the overlap of users who
are using your application and those who connect directly to the database.
If there isn't much overlap, having a separate table is probably better.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] Password encryption method

[Andrus]

> It might make more sense to use your own table of users and hashed 
> passwords
> rather than postgres'. This would depend somewhat on the overlap of users 
> who
> are using your application and those who connect directly to the database.
> If there isn't much overlap, having a separate table is probably better.

Using own table requires storing Postgres user name and password in client 
computer. Thus this information is available to virtually everyone haveing 
access to client computer.
So this is very bad idea and should avoided at all.

Andrus. 



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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Password encryption method

[Bruno Wolff III]

On Fri, Jan 19, 2007 at 18:24:32 +0200,
  Andrus <[EMAIL PROTECTED]> wrote:
> > It might make more sense to use your own table of users and hashed 
> > passwords
> > rather than postgres'. This would depend somewhat on the overlap of users 
> > who
> > are using your application and those who connect directly to the database.
> > If there isn't much overlap, having a separate table is probably better.
> 
> Using own table requires storing Postgres user name and password in client 
> computer. Thus this information is available to virtually everyone haveing 
> access to client computer.
> So this is very bad idea and should avoided at all.

No, the tables would be on the server, the same as was already being done.
Using a separate table makes it more future proof.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Password encryption method

[Bruno Wolff III]

On Sun, Jan 21, 2007 at 15:16:37 +0200,
  Andrus <[EMAIL PROTECTED]> wrote:
> 
> >No, the tables would be on the server, the same as was already being done.
> >Using a separate table makes it more future proof.
> 
> To access tables in server, you need to login into server.
> To login into server, you need postresql user name and password sent by 
> client and thus stored in client computer.
> 
> It is possible to obtain this information from client computer and use it 
> for unauthirized access to data.

This is the same problem as checking the password versus the native (to
postgres) password hashes. I suggested having private tables as an alternative
to that in order for the OP to not have problems with future upgrades, which
was the original question.

I didn't give an opinion on whether or not the whole approach was a good
idea or not, since there wasn't enough detail in the original question.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Password encryption method

[Bertram Scharpf]

Hi,

Am Montag, 22. Jan 2007, 10:25:33 -0600 schrieb Bruno Wolff III:
> I didn't give an opinion on whether or not the whole approach was a good
> idea or not, since there wasn't enough detail in the original question.

What I want to do is the following:

  1. Login in from a program on a client as a particualar user.
  2. Login from a series of scripts run by Apache on localhost
 ('trust' authentication method). Of course, I won't hand the
 password through web pages. Therefore I store something like a
 'session cookie' in a table. Next time I log in as a superuser,
 read the appropriate entry and immediately do a "set session
 autorization". The first step can be done in two ways: (a) I write
 a special login routine, (b) I log in as any other script and do
 the password check against pg_authid using the function I proposed.

Before I decide how I will solve it: thanks a lot for your
answers and for the discussion.

Bertram


-- 
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Password encryption method

[Andrus]

No, the tables would be on the server, the same as was already being done.
Using a separate table makes it more future proof.


To access tables in server, you need to login into server.
To login into server, you need postresql user name and password sent by 
client and thus stored in client computer.


It is possible to obtain this information from client computer and use it 
for unauthirized access to data.


Andrus.




---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [GENERAL] Password encryption method

[Bruno Wolff III]

On Mon, Jan 22, 2007 at 20:25:48 +0100,
  Bertram Scharpf <[EMAIL PROTECTED]> wrote:
> 
> What I want to do is the following:
> 
>   1. Login in from a program on a client as a particualar user.

For this case you shouldn't need to do anything tricky as long as the user
is login in as themselves. Just prompt the user for their password and use it
when you open a connection to the database. If you are trying to have the
program login without the user being able to steal or borrow the credentials,
then you have a serious design flaw.

>   2. Login from a series of scripts run by Apache on localhost
>  ('trust' authentication method). Of course, I won't hand the
>  password through web pages. Therefore I store something like a
>  'session cookie' in a table. Next time I log in as a superuser,
>  read the appropriate entry and immediately do a "set session
>  autorization". The first step can be done in two ways: (a) I write
>  a special login routine, (b) I log in as any other script and do
>  the password check against pg_authid using the function I proposed.

If you use trust, be sure to limit that authentication rule to expected
IP addresses and take steps to prevent spoofed packets from getting into
your network. If the web server is running on the same machine as the DB,
then consider using ident authentication and connecting using domain sockets.
(This is available under Windows.)

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Password encryption method

[Bertram Scharpf]

Hi Bruno,

Am Montag, 22. Jan 2007, 23:11:41 -0600 schrieb Bruno Wolff III:
> If the web server is running on the same machine as the DB,
> then consider using ident authentication and connecting using domain sockets.

Ah, a good suggestion. Thanks!

I found an exhaustive documentation on
.

> (This is available under Windows.)

What is "Windows"?

Bertram


-- 
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Password encryption method

[Richard Troy]

On Mon, 22 Jan 2007, Bruno Wolff III wrote:
> On Mon, Jan 22, 2007 at 20:25:48 +0100,
>   Bertram Scharpf <[EMAIL PROTECTED]> wrote:
> >
> > What I want to do is the following:
> >
> >   1. Login in from a program on a client as a particualar user.
>
> For this case you shouldn't need to do anything tricky as long as the user
> is login in as themselves. Just prompt the user for their password and use it
> when you open a connection to the database. If you are trying to have the
> program login without the user being able to steal or borrow the credentials,
> then you have a serious design flaw.

I'm quite certain I missed the start of this thread, but just looking at
the above paragraph as it stands:

Design flaw? Perhaps an _incomplete_ design, but it's only a design flaw
if not finished off properly. One way to do this cleanly is to use a
program that has the suid bit set so it runs as the program's file owner
(optionally group), and this program accesses the password and provides
the database access.

Richard


-- 
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
[EMAIL PROTECTED], http://ScienceTools.com/


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] Password encryption method

[Bruno Wolff III]

On Tue, Jan 23, 2007 at 09:44:28 +0100,
  Bertram Scharpf <[EMAIL PROTECTED]> wrote:
> Hi Bruno,
> 
> Am Montag, 22. Jan 2007, 23:11:41 -0600 schrieb Bruno Wolff III:
> > If the web server is running on the same machine as the DB,
> > then consider using ident authentication and connecting using domain 
> > sockets.
> 
> Ah, a good suggestion. Thanks!
> 
> I found an exhaustive documentation on
> .
> 
> > (This is available under Windows.)
> 
> What is "Windows"?

It was supposed to say domain sockets are NOT available under windows.

Just in case you weren't being funny, I meant the OS sold by Microsoft.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Password encryption method

[Bruno Wolff III]

On Tue, Jan 23, 2007 at 09:01:56 -0800,
  Richard Troy <[EMAIL PROTECTED]> wrote:
> 
> On Mon, 22 Jan 2007, Bruno Wolff III wrote:
> > On Mon, Jan 22, 2007 at 20:25:48 +0100,
> >   Bertram Scharpf <[EMAIL PROTECTED]> wrote:
> > >
> > > What I want to do is the following:
> > >
> > >   1. Login in from a program on a client as a particualar user.
> >
> > For this case you shouldn't need to do anything tricky as long as the user
> > is login in as themselves. Just prompt the user for their password and use 
> > it
> > when you open a connection to the database. If you are trying to have the
> > program login without the user being able to steal or borrow the 
> > credentials,
> > then you have a serious design flaw.
> 
> I'm quite certain I missed the start of this thread, but just looking at
> the above paragraph as it stands:
> 
> Design flaw? Perhaps an _incomplete_ design, but it's only a design flaw
> if not finished off properly. One way to do this cleanly is to use a
> program that has the suid bit set so it runs as the program's file owner
> (optionally group), and this program accesses the password and provides
> the database access.

You are correct. I over generalized. I should have added :and you don't control
the computer the user is running the client program on". In the case where you
do control the computer, setuid can be used to do things securely.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Password issue revisited

[Bruce Momjian]

Michael Schmidt wrote:
> Fellow PostgreSQL fans, Last year there was a pretty lengthy discussion
> (Tom Lane offered a lot of insights) on this list about deprecating
> the PGPASSWORD environmental variable.  I understand the security issues
> here very well.  However, up through version 8.1, it has been easy to
> use pg_dump and pg_restore from other applications (PHP, Java, etc.)
> by capturing the Password prompt on stderr and sending the password on
> stdin.  No more.  Now, this interaction is done on low-level I/O data
> streams.  Also, it appears from the documentation that the PGPASSFILE
> environmental variable has been deprecated for pg_dump and pg_restore.
> It appears the only way these utilities can run from a script or other
> application is to ensure that the user specified in the command-line
> has a .pgpass file.
> 
> I would like to ask that we return to outputting the Password prompt
> on stderr and accepting password input on stdin.  Here are the reasons.

Unlikely.

> 1.  I don't see that this would pose a major security risk.  In fact,
> in applications where the user enters the password for each session,
> the password need never be saved to disk, which seems a definite
> security advantage.  Some folks have noted that .pgpass is a plain text
> file, hence it could be vulnerable.

This doesn't work if the command actually is taking data from stdin.

> 2.  PostgreSQL has a tradition of respecting generally accepted
> standards.  The use of high-level input/output is a standard for many
> programming languages.

It is _not_ typical to read a password from stdin.  I am sure you can
find some tools that do this, but most do not.

> 3.  PostgreSQL has a tradition of cross-platform compatibility.  Use
> of high-level input/output allows cross-platform applications (e.g.,
> Java) to interact with PostgreSQL in a straightforward and standardized
> fashion.

> 4.  Low level input/output is considerably more difficult and less
> reliable for other applications to access and work with.

The change is to read from /dev/tty.

--
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Password issue revisited

[Tom Lane]

"Michael Schmidt" <[EMAIL PROTECTED]> writes:
> Also, it appears
> from the documentation that the PGPASSFILE environmental variable has
> been deprecated for pg_dump and pg_restore.

Eh?  Certainly not ... where did you get that idea?

> I would like to ask that we return to outputting the Password prompt on
> stderr and accepting password input on stdin.

I think it's unlikely we will revert that, as it's been a done deal for
several releases now (since 7.4 in fact).

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Password issue revisited

[Bruce Momjian]

Tom Lane wrote:
> "Michael Schmidt" <[EMAIL PROTECTED]> writes:
> > Also, it appears
> > from the documentation that the PGPASSFILE environmental variable has
> > been deprecated for pg_dump and pg_restore.
> 
> Eh?  Certainly not ... where did you get that idea?

I assumed he meant the PASSWORD environment variable.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] Password issue revisited

[Shane Ambler]

Michael Schmidt wrote:

Fellow PostgreSQL fans,


1.  I don't see that this would pose a major security risk.  In 

> fact, in applications where the user enters the password for each
> session, the password need never be saved to disk, which seems a
> definite security advantage.  Some folks have noted that .pgpass is
> a plain text file, hence it could be vulnerable.

Yes it is a plain text file but if you want to use it then you need to 
ensure the security is sufficient on the file or it won't be used.


As per the manual -

> The permissions on .pgpass must disallow any access to world or 
group; > achieve this by the command chmod 0600 ~/.pgpass. If the 
permissions

> are less strict than this, the file will be ignored. (The file
> permissions are not currently checked on Microsoft Windows, however.)


So this security feature should be something that gets added to the 
windows version. But otherwise the security of the user's account that 
has a .pgpass file is the decider on whether it is vulnerable.



--

Shane Ambler
[EMAIL PROTECTED]

Get Sheeky @ http://Sheeky.Biz

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org/

Re: [GENERAL] Password issue revisited

[Michael Schmidt]

Mr. Lane and Mr. Momjian,
Well, I asked and I got an answer.  So be it.  Regarding how I concluded that 
PGPASSFILE was deprecated for pg_dump, I offer the following.

1.  The documentation for pg_dump in the manual (Section VI) includes a section 
labeled "Environment".  This lists PGDATABASE, PGHOST, PGPORT, and PGUSER.  It 
also says "default connection parameters" but there is no hyperlink or 
reference to another manual section to explain/define this term.  

2.  Neither the Index nor the Table of Contents has an entry for "connection 
parameters" or "default connection parameters".  

3.  The application help (pg_dump --help) provides no further information.

4.  The pg_dump documentation in Section VI has a "See Also" section, with a 
link to 29.12.  In 29.12 there is a list of variables that "can be used to 
select default connection parameters" for PQconnectdb, PQsetdbLogin, and 
PQsetdb (no mention of pg_dump).  The list includes those mentioned in the 
pg_dump documentation () see 1 above) along with several others (including 
PGPASSFILE).  I was left wondering why would some of these be mentioned in the 
pg_dump section and not the others?  Perhaps those not mentioned can't be used 
by pg_dump?  

Given the above ambiguities, I was not able to conclude that pg_dump would 
accept the PGPASSFILE environment variable.

Michael Schmidt

Re: [GENERAL] Password issue revisited

[Tom Lane]

"Michael Schmidt" <[EMAIL PROTECTED]> writes:
> ... Regarding how I concluded 
> that PGPASSFILE was deprecated for pg_dump, I offer the following.

> 1.  The documentation for pg_dump in the manual (Section VI) includes a 
> section labeled "Environment".  This lists PGDATABASE, PGHOST, PGPORT, 
> and PGUSER.  It also says "default connection parameters" but there is 
> no hyperlink or reference to another manual section to explain/define 
> this term.

Yeah.  There is a link down in "See Also" but the incomplete
"Environment" section of these man pages seems misleading.

Rather than try to maintain complete lists in each of the
client-application man pages, I propose we remove those sections
completely, and just rely on the See Also links to section 29.12.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] Password issue revisited

[Bruce Momjian]

Added to TODO for Win32:

o Check .pgpass file permissions

---

Shane Ambler wrote:
> Michael Schmidt wrote:
> > Fellow PostgreSQL fans,
> 
> > 1.  I don't see that this would pose a major security risk.  In 
>  > fact, in applications where the user enters the password for each
>  > session, the password need never be saved to disk, which seems a
>  > definite security advantage.  Some folks have noted that .pgpass is
>  > a plain text file, hence it could be vulnerable.
> 
> Yes it is a plain text file but if you want to use it then you need to 
> ensure the security is sufficient on the file or it won't be used.
> 
> As per the manual -
> 
>  > The permissions on .pgpass must disallow any access to world or 
> group; > achieve this by the command chmod 0600 ~/.pgpass. If the 
> permissions
>  > are less strict than this, the file will be ignored. (The file
>  > permissions are not currently checked on Microsoft Windows, however.)
> 
> 
> So this security feature should be something that gets added to the 
> windows version. But otherwise the security of the user's account that 
> has a .pgpass file is the decider on whether it is vulnerable.
> 
> 
> -- 
> 
> Shane Ambler
> [EMAIL PROTECTED]
> 
> Get Sheeky @ http://Sheeky.Biz
> 
> ---(end of broadcast)---
> TIP 4: Have you searched our list archives?
> 
>http://archives.postgresql.org/

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Password issue revisited

[Magnus Hagander]

Are we sure we want to do this? (Sorry, didn't notice this thread last
time)

The default on *all* windows versions since NT 4.0 (which is when the
directory we use was added) will put this file in a protected directory.
The only case when it's not protected by default is if you're usnig FAT
filesystem, in which case there is nothing you can do about it anyway.
On unix, the file will often be created in outside-readable mode by
default, depending on how your OS is set up.

So to reach a situation where the file lives in an unprotected
directory, you must actively open up the directory in question. Which is
hidden from default view, so you really need to know what you're doing to
get there.

Not to mention it's a pain to define what permissions are ok and what
are not. We're talking ACLs and not filemodes - so how do you decide
which accounts are ok to have access, and which are not?

//Magnus



On Tue, Feb 20, 2007 at 09:49:00AM -0500, Bruce Momjian wrote:
> 
> Added to TODO for Win32:
> 
> o Check .pgpass file permissions
> 
> ---
> 
> Shane Ambler wrote:
> > Michael Schmidt wrote:
> > > Fellow PostgreSQL fans,
> > 
> > > 1.  I don't see that this would pose a major security risk.  In 
> >  > fact, in applications where the user enters the password for each
> >  > session, the password need never be saved to disk, which seems a
> >  > definite security advantage.  Some folks have noted that .pgpass is
> >  > a plain text file, hence it could be vulnerable.
> > 
> > Yes it is a plain text file but if you want to use it then you need to 
> > ensure the security is sufficient on the file or it won't be used.
> > 
> > As per the manual -
> > 
> >  > The permissions on .pgpass must disallow any access to world or 
> > group; > achieve this by the command chmod 0600 ~/.pgpass. If the 
> > permissions
> >  > are less strict than this, the file will be ignored. (The file
> >  > permissions are not currently checked on Microsoft Windows, however.)
> > 
> > 
> > So this security feature should be something that gets added to the 
> > windows version. But otherwise the security of the user's account that 
> > has a .pgpass file is the decider on whether it is vulnerable.

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] Password issue revisited

[Bruce Momjian]

Magnus Hagander wrote:
> Are we sure we want to do this? (Sorry, didn't notice this thread last
> time)
> 
> The default on *all* windows versions since NT 4.0 (which is when the
> directory we use was added) will put this file in a protected directory.
> The only case when it's not protected by default is if you're usnig FAT
> filesystem, in which case there is nothing you can do about it anyway.
> On unix, the file will often be created in outside-readable mode by
> default, depending on how your OS is set up.
> 
> So to reach a situation where the file lives in an unprotected
> directory, you must actively open up the directory in question. Which is
> hidden from default view, so you really need to know what you're doing to
> get there.
> 
> Not to mention it's a pain to define what permissions are ok and what
> are not. We're talking ACLs and not filemodes - so how do you decide
> which accounts are ok to have access, and which are not?

OK, I added a comment to fe-connect.c explaining why we don't need to
check the permissions of .pgpass, and removed the TODO.  Thanks.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [GENERAL] Password issue revisited

[Shane Ambler]

Bruce Momjian wrote:

Magnus Hagander wrote:

Are we sure we want to do this? (Sorry, didn't notice this thread last
time)

The default on *all* windows versions since NT 4.0 (which is when the
directory we use was added) will put this file in a protected directory.
The only case when it's not protected by default is if you're usnig FAT
filesystem, in which case there is nothing you can do about it anyway.
On unix, the file will often be created in outside-readable mode by
default, depending on how your OS is set up.


I believe that .pgpass on *nix won't be used if it is readable by anyone 
except the current user.


From the docs -
The permissions on .pgpass must disallow any access to world or group; 
achieve this by the command chmod 0600 ~/.pgpass. If the permissions are 
less strict than this, the file will be ignored. (The file permissions 
are not currently checked on Microsoft Windows, however.)


I would think that if they are using FAT filesystem (which is only 
partially supported for developers benefit) then they can't use pgpass.



So to reach a situation where the file lives in an unprotected
directory, you must actively open up the directory in question. Which is
hidden from default view, so you really need to know what you're doing to
get there.

Not to mention it's a pain to define what permissions are ok and what
are not. We're talking ACLs and not filemodes - so how do you decide
which accounts are ok to have access, and which are not?


I would say the same as the *nix version - if it is readable or writable 
by anyone except the current user it is potentially at risk, the current 
user connecting to pgsql is the only use for this file.
Which I believe is the whole point of the TODO entry, stop anyone using 
the pgpass file without proper security.


The other thing to consider is that pgpass is the file referenced by 
PGPASSFILE - the user can set this to point to a file anywhere on any 
drive available.


It is users who only think they know what they are doing that create and 
modify it by hand and then kick up a fuss when it causes trouble.


If we want the windows clients to be used then I do think that the 
security decisions should not be dropped for windows clients.



OK, I added a comment to fe-connect.c explaining why we don't need to
check the permissions of .pgpass, and removed the TODO.  Thanks.




--

Shane Ambler
[EMAIL PROTECTED]

Get Sheeky @ http://Sheeky.Biz

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org/

Re: [GENERAL] Password issue revisited

[Magnus Hagander]

>>> The default on *all* windows versions since NT 4.0 (which is when the
>>> directory we use was added) will put this file in a protected directory.
>>> The only case when it's not protected by default is if you're usnig FAT
>>> filesystem, in which case there is nothing you can do about it anyway.
>>> On unix, the file will often be created in outside-readable mode by
>>> default, depending on how your OS is set up.
> 
> I believe that .pgpass on *nix won't be used if it is readable by anyone
> except the current user.

No, root can always read it. On unix, there is one "root". On windows,
the concept of administrator is less clear.


> From the docs -
> The permissions on .pgpass must disallow any access to world or group;
> achieve this by the command chmod 0600 ~/.pgpass. If the permissions are
> less strict than this, the file will be ignored. (The file permissions
> are not currently checked on Microsoft Windows, however.)
> 
> I would think that if they are using FAT filesystem (which is only
> partially supported for developers benefit) then they can't use pgpass.

If they are using FAT, the obviously don't care about the security of
the system anyway, so it's not a problem, IMHO. So we only have to care
about people who use NTFS.


>>> So to reach a situation where the file lives in an unprotected
>>> directory, you must actively open up the directory in question. Which is
>>> hidden from default view, so you really need to know what you're
>>> doing to
>>> get there.
>>>
>>> Not to mention it's a pain to define what permissions are ok and what
>>> are not. We're talking ACLs and not filemodes - so how do you decide
>>> which accounts are ok to have access, and which are not?
> 
> I would say the same as the *nix version - if it is readable or writable
> by anyone except the current user it is potentially at risk, the current
> user connecting to pgsql is the only use for this file.
> Which I believe is the whole point of the TODO entry, stop anyone using
> the pgpass file without proper security.

Again, it's a lot harder to actually define it on Windows. What if your
user has access only through a group? What about DENY permissions.
Things like that.


> The other thing to consider is that pgpass is the file referenced by
> PGPASSFILE - the user can set this to point to a file anywhere on any
> drive available.

That's a very valid point though, didn't think about that.

Still doesn't take away the "how" part, though, but it does take away
part of the "why" part.

//Magnus


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] Password issue revisited

[Bruce Momjian]

Tom Lane wrote:
> "Michael Schmidt" <[EMAIL PROTECTED]> writes:
> > ... Regarding how I concluded 
> > that PGPASSFILE was deprecated for pg_dump, I offer the following.
> 
> > 1.  The documentation for pg_dump in the manual (Section VI) includes a 
> > section labeled "Environment".  This lists PGDATABASE, PGHOST, PGPORT, 
> > and PGUSER.  It also says "default connection parameters" but there is 
> > no hyperlink or reference to another manual section to explain/define 
> > this term.
> 
> Yeah.  There is a link down in "See Also" but the incomplete
> "Environment" section of these man pages seems misleading.
> 
> Rather than try to maintain complete lists in each of the
> client-application man pages, I propose we remove those sections
> completely, and just rely on the See Also links to section 29.12.

I think we can conclude that adding libpq in the "See Also" section of
the documentation isn't sufficient.  I have removed that mention, and
added this text to the bottom of the "Environment" section for each
utility:

+This utility, like most other PostgreSQL utilities,
+also uses the environment variables supported by .

I have backpatched this to 8.2.X.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Password issue revisited

[Tony Caduto]

Magnus Hagander wrote:

Are we sure we want to do this? (Sorry, didn't notice this thread last
time)

The default on *all* windows versions since NT 4.0 (which is when the
directory we use was added) will put this file in a protected directory.
  
Is there truly such a thing on a windows PC?  All it takes is one Virus 
or Malware to gain access to the PC and anything stored in the

user profile is easy picking.
The virus and malware creators may not know about the pg_pass file now, 
but they will eventually.
What about having a wallet type system where the user can create a pass 
phrase to protect a generated key that would get

loaded once per session.  That is how KDE allows users to store passwords.

I work at a large financial institution and if the auditors knew about 
the pg_pass being plain text, they would pretty much ban

it's use.

Anytime a password is sitting on a non encrypted file system, regardless 
of it's permissions it is potentially at risk.


--
Tony 



---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] Password issue revisited

[Magnus Hagander]

Tony Caduto wrote:
> Magnus Hagander wrote:
>> Are we sure we want to do this? (Sorry, didn't notice this thread last
>> time)
>>
>> The default on *all* windows versions since NT 4.0 (which is when the
>> directory we use was added) will put this file in a protected directory.
>>   
> Is there truly such a thing on a windows PC?  All it takes is one Virus
> or Malware to gain access to the PC and anything stored in the
> user profile is easy picking.
> The virus and malware creators may not know about the pg_pass file now,
> but they will eventually.
> What about having a wallet type system where the user can create a pass
> phrase to protect a generated key that would get
> loaded once per session.  That is how KDE allows users to store passwords.
> 
> I work at a large financial institution and if the auditors knew about
> the pg_pass being plain text, they would pretty much ban
> it's use.
> 
> Anytime a password is sitting on a non encrypted file system, regardless
> of it's permissions it is potentially at risk.

If we wanted to do that, we could use the Windows API that's available
to do this. The idea with the pgpass flie is to have it compatible with
the unix version.

//Magnus

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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Password issue revisited

[Tom Lane]

Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tony Caduto wrote:
>> What about having a wallet type system where the user can create a pass
>> phrase to protect a generated key that would get
>> loaded once per session.  That is how KDE allows users to store passwords.

> If we wanted to do that, we could use the Windows API that's available
> to do this. The idea with the pgpass flie is to have it compatible with
> the unix version.

More to the point, that's far outside the scope of this project.  Use a
PAM auth module that you like, or Kerberos or whatever.  I'm way past
tired of "let's put yet another authentication technology in libpq" requests.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] Password issue revisited

[Magnus Hagander]

Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tony Caduto wrote:
>>> What about having a wallet type system where the user can create a pass
>>> phrase to protect a generated key that would get
>>> loaded once per session.  That is how KDE allows users to store passwords.
> 
>> If we wanted to do that, we could use the Windows API that's available
>> to do this. The idea with the pgpass flie is to have it compatible with
>> the unix version.
> 
> More to the point, that's far outside the scope of this project.  Use a
> PAM auth module that you like, or Kerberos or whatever.  I'm way past
> tired of "let's put yet another authentication technology in libpq" requests.

Just to make things clear, this wouldn't be about another auth method.
Windows has an API to store arbitrary passwords in a "secure way". At
least it does in XP+, not sure if it was in 2000.

Not saying it's a good idea, but it's not another auth tech for libpq.

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [GENERAL] Password issue revisited

[Dave Page]

Magnus Hagander wrote:

> Just to make things clear, this wouldn't be about another auth method.
> Windows has an API to store arbitrary passwords in a "secure way". At
> least it does in XP+, not sure if it was in 2000.

Would it really solve Tony's problem though? I'm not familiar with the
API you're thinking of, but do be useful to us it must be able to give
the unencrypted passwords back to us, and therefore anything else
pretending to be us.

Regards, Dave.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Password issue revisited

[Magnus Hagander]

Dave Page wrote:
> Magnus Hagander wrote:
> 
>> Just to make things clear, this wouldn't be about another auth method.
>> Windows has an API to store arbitrary passwords in a "secure way". At
>> least it does in XP+, not sure if it was in 2000.
> 
> Would it really solve Tony's problem though? I'm not familiar with the
> API you're thinking of, but do be useful to us it must be able to give
> the unencrypted passwords back to us, and therefore anything else
> pretending to be us.

yeah, but it pops up a GUI notification for you. It's what IE uses to
store things like passports. It's also used, IIRC, by the new RDP client
that's available, and a few more.
Did a quick check, and it's XP/2003 only. See
http://msdn2.microsoft.com/en-us/library/aa302353.aspx.

//Magnus

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Password issue revisited

[Dave Page]

Magnus Hagander wrote:
> Dave Page wrote:
>> Magnus Hagander wrote:
>>
>>> Just to make things clear, this wouldn't be about another auth method.
>>> Windows has an API to store arbitrary passwords in a "secure way". At
>>> least it does in XP+, not sure if it was in 2000.
>> Would it really solve Tony's problem though? I'm not familiar with the
>> API you're thinking of, but do be useful to us it must be able to give
>> the unencrypted passwords back to us, and therefore anything else
>> pretending to be us.
> 
> yeah, but it pops up a GUI notification for you. It's what IE uses to
> store things like passports. It's also used, IIRC, by the new RDP client
> that's available, and a few more.
> Did a quick check, and it's XP/2003 only. See
> http://msdn2.microsoft.com/en-us/library/aa302353.aspx.

That would break all the non-interactive apps that we recommend using
pgpass with to prevent storing passwords in even less secure places.

Regards, Dave.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Password issue revisited

[Bruce Momjian]

I assume this is not a TODO.

---

Magnus Hagander wrote:
> >>> The default on *all* windows versions since NT 4.0 (which is when the
> >>> directory we use was added) will put this file in a protected directory.
> >>> The only case when it's not protected by default is if you're usnig FAT
> >>> filesystem, in which case there is nothing you can do about it anyway.
> >>> On unix, the file will often be created in outside-readable mode by
> >>> default, depending on how your OS is set up.
> > 
> > I believe that .pgpass on *nix won't be used if it is readable by anyone
> > except the current user.
> 
> No, root can always read it. On unix, there is one "root". On windows,
> the concept of administrator is less clear.
> 
> 
> > From the docs -
> > The permissions on .pgpass must disallow any access to world or group;
> > achieve this by the command chmod 0600 ~/.pgpass. If the permissions are
> > less strict than this, the file will be ignored. (The file permissions
> > are not currently checked on Microsoft Windows, however.)
> > 
> > I would think that if they are using FAT filesystem (which is only
> > partially supported for developers benefit) then they can't use pgpass.
> 
> If they are using FAT, the obviously don't care about the security of
> the system anyway, so it's not a problem, IMHO. So we only have to care
> about people who use NTFS.
> 
> 
> >>> So to reach a situation where the file lives in an unprotected
> >>> directory, you must actively open up the directory in question. Which is
> >>> hidden from default view, so you really need to know what you're
> >>> doing to
> >>> get there.
> >>>
> >>> Not to mention it's a pain to define what permissions are ok and what
> >>> are not. We're talking ACLs and not filemodes - so how do you decide
> >>> which accounts are ok to have access, and which are not?
> > 
> > I would say the same as the *nix version - if it is readable or writable
> > by anyone except the current user it is potentially at risk, the current
> > user connecting to pgsql is the only use for this file.
> > Which I believe is the whole point of the TODO entry, stop anyone using
> > the pgpass file without proper security.
> 
> Again, it's a lot harder to actually define it on Windows. What if your
> user has access only through a group? What about DENY permissions.
> Things like that.
> 
> 
> > The other thing to consider is that pgpass is the file referenced by
> > PGPASSFILE - the user can set this to point to a file anywhere on any
> > drive available.
> 
> That's a very valid point though, didn't think about that.
> 
> Still doesn't take away the "how" part, though, but it does take away
> part of the "why" part.
> 
> //Magnus
> 
> 
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Password for postgres

[Shoaib Mir]

The command goes through fine, but the next time I log into postgres using

the command,
>>psql mydb postgres
>>it logs in, and doesnt ask me for a password at all. If I issue a command
like,

This is because you have trust in pg_hba.conf file, change it to md5 so it
asks for password every time you log in :)


psql mydb postgres mypwd


That is not the correct way, just as i mentioned change it to md5 and now
when you do

psql -d mydb -U postgres

It will ask for a password.

--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)

On 3/8/07, George Heller <[EMAIL PROTECTED]> wrote:


Hi all,

I am using a postgres database, and want to set a password for the
account. The default user name is 'postgres' and in order to set a password,
I did an alter user as below,

alter user postgres with password 'mypwd';

The command goes through fine, but the next time I log into postgres using
the command,

psql mydb postgres

it logs in, and doesnt ask me for a password at all. If I issue a command
like,

psql mydb postgres mypwd

it says, extra argument!!! I have checked the pg_shadow table, and it
looks like the password has been set. I also have a trust entry for the
database server that I am accessing it through, in the pg_hba.conf file.

Any suggestions to get around this problem?

Thanks!
George

--
Need Mail bonding?
Go to the Yahoo! Mail 
Q&Afor
 great
tips from Yahoo! 
Answersusers.

Re: [GENERAL] Password authentication failed

[Jan Bilek]

Connect to PostgreSql as Postgres user (default database user):

psql yourdb -U Postgres

then you will be asked for password selected during the installation.

Hope this will help.

JB

  - Original Message - 
  From: Suresh Nimbalkar 
  To: pgsql-general@postgresql.org 
  Sent: Tuesday, May 01, 2007 1:29 PM
  Subject: [GENERAL] Password authentication failed


  Hi!

  I am a complete newbee to Postgres. Have installed Postgres on Windows 2003 
server SP1 a week back. When I try to log-in to the server (by writting psql 
mydb at command prompt in postgres/bin directory), I keep getting a message 
"psal: FATAL: password authentication failed for user"Administrator". 

  I have installed Postgres as an Administrator and log-in to the server as 
administrator. I don't think I am making mistake in entering the password. 

  It's quite frustrating. Will someone please help?

  Thanks and regards
  Vedsur



--
  Ahhh...imagining that irresistible "new car" smell?
  Check out new cars at Yahoo! Autos. 

Re: [GENERAL] Password Encryption / PgAdmin

[Tino Wildenhain]

Am Dienstag, den 17.05.2005, 12:36 +0200 schrieb
[EMAIL PROTECTED]:
> Hi,
>  
> I set a PostgreSQL server with users who have Encrypted passwords.
> Is there a way to connect to the database using one of these users
> through pgAdmin ? 
> Is there a way to tell pgAdmin to encrypt the password...
>  

You just use the password in pgadmin and thats all.
 
-- 
Tino Wildenhain <[EMAIL PROTECTED]>


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [GENERAL] Password Encryption / PgAdmin

[Patrick . FICHE]

Thanks,

I forgot to mention md5 encryption in pg_hba.conf...


--- 
Patrick Fiche 
email : [EMAIL PROTECTED] 
tél : 01 69 29 36 18 

--- 




-Original Message-
From: Tino Wildenhain [mailto:[EMAIL PROTECTED]
Sent: mardi 17 mai 2005 13:26
To: [EMAIL PROTECTED]
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Password Encryption / PgAdmin


Am Dienstag, den 17.05.2005, 12:36 +0200 schrieb
[EMAIL PROTECTED]:
> Hi,
>  
> I set a PostgreSQL server with users who have Encrypted passwords.
> Is there a way to connect to the database using one of these users
> through pgAdmin ? 
> Is there a way to tell pgAdmin to encrypt the password...
>  

You just use the password in pgadmin and thats all.
 
-- 
Tino Wildenhain <[EMAIL PROTECTED]>


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [GENERAL] Password strength requirements

[Steve Atkins]

On Dec 21, 2006, at 7:08 AM, Tomasz Ostrowski wrote:


I'm working on a project which needs to satisfy some legal
requirements for password strength. But any postgresql user can do;
alter role [session_user] password 'foo';

Is there any way to disallow self changing of password by ordinary
users? Or force password strength in any other way?


If you check http://www.postgresql.org/docs/8.2/static/client- 
authentication.html
you'll see a bunch of different ways to authenticate users. Most of  
them are
external to the database, so don't allow changing the password from  
within

the database.

One of those should satisfy your needs - PAM in particular allows you to
plugin a huge variety of backends to provide a lot of different  
behaviors.


Cheers,
  Steve



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

  http://www.postgresql.org/docs/faq

Re: [GENERAL] Password strength requirements

[Tomasz Ostrowski]

On Thu, 21 Dec 2006, Steve Atkins wrote:

> >Is there any way to disallow self changing of password by ordinary
> >users? Or force password strength in any other way?
> 
> If you check 
> http://www.postgresql.org/docs/8.2/static/client-authentication.html
> you'll see a bunch of different ways to authenticate users. Most of
> them are external to the database, so don't allow changing the
> password from within the database.

But I need an ability to change passwords. The easiest way to do it
would be to create a "security definer" function owned by a role with
"create role" privilege that checks password strength and changes
password, for example:
create or replace function change_password(_password text)
returns void
language plpgsql
volatile
security definer
as $function$
begin
if (
char_length(_password)<8
or _password !~ '[A-Z]'
or _password !~ '[a-z]'
or _password !~ '[0-9]'
) then
raise exception 'Password too weak, because ...';
end if;
execute 'alter user ' || quote_ident(session_user)
|| ' password ' || quote_literal(_password)
|| ' valid until ' || 
quote_literal(current_timestamp+'60 days'::interval);
return;
end;
$function$;
But any user can change his password using 'alter user ... password
...'. If there was any way of preventing users without "create role"
privilege from changing their own passwords this would be good enough.
I'll just need to ensure encrypted connections to the database.

If I had to use external authentication it'd need a lot of work - I'd
need to learn, setup, document and maintain this external
authentication, provide a way of changing passwords securely other
than using a database, create one more single point of failure,
etc...

Or I'll just ignore this possibility of choosing weak password. It
would not reset account validity time anyway. Also nobody would
notice - application interface will use this change_password function
- it's just not the right way.

Regards
Tometzky
-- 
...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
were...
  Winnie the Pooh

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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Password strength requirements

[Bruno Wolff III]

On Thu, Dec 21, 2006 at 21:04:33 +0100,
  Tomasz Ostrowski <[EMAIL PROTECTED]> wrote:
> 
> But I need an ability to change passwords. The easiest way to do it

But do you have to use the native passwords in Postgres? If you use ldap or
pam, you could use passwords maintained somewhere else that had more strict
requirements.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Password strength requirements

[Tomasz Ostrowski]

On Thu, 21 Dec 2006, Bruno Wolff III wrote:

> > But I need an ability to change passwords.
> 
> But do you have to use the native passwords in Postgres? If you use
> ldap or pam, you could use passwords maintained somewhere else that
> had more strict requirements.

As I've written earlier I'd have to:
- learn and understand this LDAP/PAM - how to use it, how to change
  passwords remotely, how to define password strength requirements,
  etc.
- setup and maintain this services, creating another single point of
  failure,
- document it for the future system administrator,
- implement password change function in application, using secure
  transport.

And everything I need would be very simple to do if there was an
option to disable self-change of passwords for ordinary users.

I'm writing here, because I have a problem with PostgreSQL, for which
I can see a simple solution if PostgreSQL would have one more simple
feature. I hoped I've overlooked something in the documentation and
this feature is present. If not, then maybe someone else would also
need this, and it'll perhaps make it to the TODO list.

Regards
Tometzky
-- 
...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
were...
  Winnie the Pooh

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Password strength requirements

[Tom Lane]

Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> And everything I need would be very simple to do if there was an
> option to disable self-change of passwords for ordinary users.

If you are using PAM authentication, the password recorded by Postgres
is irrelevant, so I'm not seeing what the problem is.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Password strength requirements

[Bruno Wolff III]

On Thu, Dec 21, 2006 at 23:43:06 +0100,
  Tomasz Ostrowski <[EMAIL PROTECTED]> wrote:
> 
> And everything I need would be very simple to do if there was an
> option to disable self-change of passwords for ordinary users.

That seems like a feature not many other people are going to want.
You have the soruce, and it probably wouldn't be too hard to put
in a hack to do that.

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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Password strength requirements

[Rafal Pietrak]

On Fri, 2006-12-22 at 01:20 -0600, Bruno Wolff III wrote:
> On Thu, Dec 21, 2006 at 23:43:06 +0100,
>   Tomasz Ostrowski <[EMAIL PROTECTED]> wrote:
> > 
> > And everything I need would be very simple to do if there was an
> > option to disable self-change of passwords for ordinary users.
> 
> That seems like a feature not many other people are going to want.
> You have the soruce, and it probably wouldn't be too hard to put
> in a hack to do that.

I must say, that I was tempted to try. Even though I'm at all fit to.

In my case, it is not because of blocking of self-password change, but
on quite a similar token I need:
1. password expiration - which works on the database level in such a
way, that when account/password expire, only "alter... password .."
statement is allowed for such a user. *all* other SQL statements should
result in "RAISE EXCEPTION... " - that is: transaction aborted.
2. I also need some additional *per*session* fields (of the
"client_encoding" or "search_path" variaty) in the SET/SHOW environment.

Still, I have *never* hacked the postgres, so I'm a bit reluctant here -
this may be more then a little project I fear.

But if I try, could you pls hint me on which source files and/or
functions should I start with?

Or may be the there is a "quick start for hackers" HOWTO somwhere
around?

BTW: One of the reasons I need the hack for password change/expiry is
that neither of the two 'possible' alternatives: PAM or LDAP, do not
allow for "CREATE USER ..." as per documentation in:
"http://www.postgresql.org/docs/8.2/static/auth-methods.html#AUTH-LDAP"; (but 
may be I'm missinterpreting the docs?)

And LDAP, although most atractive, is further unnecesarly constrained by
a depencecy on SASL.

and putting more oil into the fire. LDAP is not actually a database
- it's an '...Access Protocol', so we may choose freely the 'LDAP
backend database' ... a good relational database like postgres is an
option here  and this is a real mass.

So I think postgres should have more extensive *native* support for
password authentication, and I'm willing to hack  but provided my
lack of experience - pointers to HOWTOs apreciated :)

-- 
-R

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [GENERAL] Password and Installation

[Dave Page]

On Fri, Nov 21, 2008 at 10:30 PM, Andrew Maeng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I recently uninstalled PostgreSQL, and now am attempting to reinstall it on
> a Windows Vista OS. However, I don't remember the password that was used to
> install PostgreSQL before, and am prompted with "The password specified was
> incorrect. Please enter the correct password for the postgres windows user
> account."
>
> I'm guessing that PostgreSQL wasn't fully uninstalled previously, and there
> are still some registry files or data files somewhere? Can my old password
> somehow be retrieved?

No - it's a Windows user account, so the password cannot be retrieved
any more than your Administrator password can.

I don't know what the equivalent on Vista is, but on XP, open the
Computer Management tool under Administrative Tools, and you can reset
the password under the users section.

-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Password and Installation

[Dave Page]

Hi Andrew,

On Mon, Nov 24, 2008 at 12:10 AM, Andrew Maeng <[EMAIL PROTECTED]> wrote:
> Thanks Dave. I can't seem to find the SQL user in the user accounts though.
> All i can see is the asp.net machine account.

Look for a user called 'postgres', not SQL.

> I'm guessing that this means that PostgreSQL is uninstalled, but I'm still
> unable to install PostgreSQL because I'm putting in the "wrong password".

The uninstaller doesn't remove the postgres user account because it
doesn't have any way of knowing if you're using it for other tools or
different versions of PostgreSQL. If the installer is reporting that
the password is incorrect, that's because there's an existing account
and Windows is telling us the password is wrong. If you can't find the
account for whatever reason, another way of removing it is to use the
command line tools. From a command prompt with administrator
privileges, try:

net user postgres /delete

It *should* be shown in the computer management applet though - but
the user accounts tool in Control Panel will hide service accounts (I
assume that applies to Vista as well as XP).

Regards, Dave.


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password for postgres

[Abdul Rahman]

Kindly let me know two things to answer you. First, Are you trying to start 
postgres service or psql prompt? second, what OS is in your use.



  

Re: [GENERAL] password for postgres

[Adrian Klaver]

On Friday 13 February 2009 2:18:32 am Kusuma Pabba wrote:
> i don't  know y am i getting this problem
>
> when i try to start off postgres
> it asks me for password:

Are trying to start the Postgres program or are you trying to connect to an 
already running server?

>
>
> i did not set any password as such
>
> except that when the first day i used template, i ahve used the below
> two statements
> ALTER USER postgres with encrypted password 'your_password';
> ALTER USER postgres with encrypted password 'welcome';

If you did it that order then your password for connecting should be 'welcome'.
User/role information is cluster wide. If you entered the above to access the 
template then it is in effect for all databases in the cluster.

Are you connecting as the user postgres or another user? 

>
> but it is not accepting both the passwords
> i am getting incorrect password after three trials it is returning back
> to command prompt

What is the error message that you are getting?
Have you set up the pg_hba.conf file correctly?
See http://www.postgresql.org/docs/8.3/interactive/client-authentication.html 
for more information.


>
> when i have used
> select * from pg_shadow;
> then i got
>
> md5d31faa0b92fad4e2d8e4af34a30f890b

I am assuming this is for the user postgres.

>
> though i use this i am not able to acess i don't  know what to do with
> this issue
> can any one shed light on me by explaining me what was the mistake i did
> or which password to use
> thanks for any help
>
>
> Regards
> kusuma.p



-- 
Adrian Klaver
akla...@comcast.net

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password for postgres

[Sim Zacks]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

You do not want to use the keyword encrypted.
To get in, go to your pg_hba file and set the security level to trust
for your account. Then go in as postgres without a password and change
it by:
alter role postgres with password 'welcome';


> ALTER USER postgres with encrypted password 'your_password';
> ALTER USER postgres with encrypted password 'welcome';
> 
> but it is not accepting both the passwords
> i am getting incorrect password after three trials it is returning back
> to command prompt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmXsSQACgkQjDX6szCBa+poGACgxKo0aHk+7+XzsdlOLVnPD0zY
aJ8An0ArIlUvz19M3um4HS7wS1BW6ZC3
=sbx/
-END PGP SIGNATURE-

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password for postgres

[Jasen Betts]

On 2009-02-13, Kusuma Pabba  wrote:
> i don't  know y am i getting this problem
>
> when i try to start off postgres
> it asks me for password:

what OS.

what command are you using?


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password option in pg_dumpall

[Tom Lane]

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> is there anyway of specifying password in the command line interface
> of pg_dumpall??

No, and you wouldn't want to use it if there was (hint: putting a
password on a command line is insecure).

The recommended procedure to avoid a lot of password prompts is to
set up a ~/.pgpass file:
http://www.postgresql.org/docs/8.2/static/libpq-pgpass.html

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] Password for postgresql superuser?

[jqpx37]

Sorry; I meant a password at the operating system level, not at the postgresql 
level.

On my Linux system, without an OS level password, the only way to log in (in 
Linux) to the postgres account is by su'ing from root, which seems more secure 
than having a password for the postgres account.

- Original Message -
From: "jqpx37" <[EMAIL PROTECTED]>
To: pgsql-general@postgresql.org
Sent: Thursday, June 08, 2006 11:05 AM
Subject: [GENERAL] Password for postgresql superuser?

 Is there any security risk in the postgresql superuser having a password?
 
 I installed a Linux distro recently and had it install Postgresql.  It 
automatically set up the postgres account; the account was set up with no 
password.
 
 I could of course create a password, but it's not clear to me that's a good 
thing from a security standpoint.
 ---(end of broadcast)---
 TIP 3: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faq
---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [GENERAL] Password for postgresql superuser?

[Rafal Pietrak]

On Thu, 2006-06-08 at 09:08 -0600, jqpx37 wrote:
> Sorry; I meant a password at the operating system level, not at the 
> postgresql level.
> 
> On my Linux system, without an OS level password, the only way to log in (in 
> Linux) to the postgres account is by su'ing from root, which seems more 
> secure than having a password for the postgres account.

Have you tried sudo ("sudo" command)? 

It asks for a personal password, and grants whatever priviledge is
configured for that person, even root priviledge.

-R

> - Original Message -
> From: "jqpx37" <[EMAIL PROTECTED]>
> To: pgsql-general@postgresql.org
> Sent: Thursday, June 08, 2006 11:05 AM
> Subject: [GENERAL] Password for postgresql superuser?
> 
>  Is there any security risk in the postgresql superuser having a password?
>  
>  I installed a Linux distro recently and had it install Postgresql.  It 
> automatically set up the postgres account; the account was set up with no 
> password.
>  
>  I could of course create a password, but it's not clear to me that's a good 
> thing from a security standpoint.
>  ---(end of broadcast)---
>  TIP 3: Have you checked our extensive FAQ?
>  
> http://www.postgresql.org/docs/faq
> ---(end of broadcast)---
> TIP 4: Have you searched our list archives?
> 
>http://archives.postgresql.org
-- 
-R

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Password for postgresql superuser?

[Chris Browne]

[EMAIL PROTECTED] ("jqpx37") writes:

> Is there any security risk in the postgresql superuser having a
> password?
>
> I installed a Linux distro recently and had it install Postgresql.
> It automatically set up the postgres account; the account was set up
> with no password.
>
> I could of course create a password, but it's not clear to me that's
> a good thing from a security standpoint.

That depends on your security policies.

There's a pretty good argument to be made that a 'postgres' account
should only permit people in via "su -", in which case it might not
need to have an individual password...
-- 
(format nil "[EMAIL PROTECTED]" "cbbrowne" "cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/oses.html
"If you give someone Fortran, he has Fortran.
If you give someone Lisp, he has any language he pleases."
-- Guy L. Steele Jr.

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

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Password for postgresql superuser?

[jqpx37]

- Original Message -
From: "Chris Browne" <[EMAIL PROTECTED]>
To: pgsql-general@postgresql.org
Sent: Thursday, June 08, 2006 01:30 PM
Subject: [GENERAL] Password for postgresql superuser?

> [EMAIL PROTECTED] ("jqpx37") writes:
> 
> > Is there any security risk in the postgresql superuser having a
> > password?
> >
> > I installed a Linux distro recently and had it install Postgresql.
> > It automatically set up the postgres account; the account was set up
> > with no password.
> >
> > I could of course create a password, but it's not clear to me that's
> > a good thing from a security standpoint.
> 
> That depends on your security policies.
> 
> There's a pretty good argument to be made that a 'postgres' account
> should only permit people in via "su -", in which case it might not
> need to have an individual password...

Thanks for your response.

I found allusions to the point your making, though no detailed explanation.  It 
makes sense even without a thorough explication.

Best wishes

> -- 
> (format nil "[EMAIL PROTECTED]" "cbbrowne" "cbbrowne.com")
> http://www3.sympatico.ca/cbbrowne/oses.html
> "If you give someone Fortran, he has Fortran.
> If you give someone Lisp, he has any language he pleases."
> -- Guy L. Steele Jr.
> 
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
> 
>http://www.postgresql.org/docs/faq
---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [GENERAL] PASSWORD vs. md5('somepass')

[Josh Kupershmidt]

On Tue, Mar 20, 2012 at 8:28 AM, Alexander Reichstadt  wrote:
> Hi,
>
> I look for a way to reproduce the encrypted string stored as a password by 
> means other than using the CREATE ROLE command.
>
> When using CREATE ROLEPASSWORD 'somepass' the resulting string for 
> rolpassword in pg_authid always starts with md5, suggesting it would create 
> some md5 string. So I thought to use SELECT md5('somepass') to get the same.
>
> But the two strings differ. Is there a function that does that outside the 
> create role context?

See pg_authid's explanation of the rolpassword column:
  http://www.postgresql.org/docs/9.1/static/catalog-pg-authid.html

which you can reproduce via:
  SELECT 'md5' || MD5(role_password_here || role_name_here);

Josh

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PASSWORD vs. md5('somepass')

[Alexander Reichstadt]

Thanks, I was here 
.

Am 20.03.2012 um 16:55 schrieb Josh Kupershmidt:

> On Tue, Mar 20, 2012 at 8:28 AM, Alexander Reichstadt  wrote:
>> Hi,
>> 
>> I look for a way to reproduce the encrypted string stored as a password by 
>> means other than using the CREATE ROLE command.
>> 
>> When using CREATE ROLEPASSWORD 'somepass' the resulting string for 
>> rolpassword in pg_authid always starts with md5, suggesting it would create 
>> some md5 string. So I thought to use SELECT md5('somepass') to get the same.
>> 
>> But the two strings differ. Is there a function that does that outside the 
>> create role context?
> 
> See pg_authid's explanation of the rolpassword column:
>  http://www.postgresql.org/docs/9.1/static/catalog-pg-authid.html
> 
> which you can reproduce via:
>  SELECT 'md5' || MD5(role_password_here || role_name_here);
> 
> Josh
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] password authentication failed for ..

[Doug McNaught]

"Manu M P" <[EMAIL PROTECTED]> writes:

> Hi
>
> I have the data base "test" and two users "test1" "test2". I added the following 
> record to pg_hba.conf
>
> local test password passwords
>
> I then created the "passwords" file in $PGDATA using pg_pasword and
> added entries for the two users "test1" and "test2".

Ummm...

Passwords are stored in the 'pg_shadow' table and set using
CREATE/ALTER USER, not in a file.

I've never heard of a 'pg_password' program and it is not part of the
standard distribution.

-Doug

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [GENERAL] password authentication failed for ..

[Tom Lane]

Doug McNaught <[EMAIL PROTECTED]> writes:
> "Manu M P" <[EMAIL PROTECTED]> writes:
>> I then created the "passwords" file in $PGDATA using pg_pasword and
>> added entries for the two users "test1" and "test2".

> I've never heard of a 'pg_password' program and it is not part of the
> standard distribution.

pg_passwd did exist in releases up to 7.2, but we got rid of it because
that functionality got moved into ALTER USER.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [GENERAL] PASSWORD() function for postgresql?

[Thalis A. Kalfigopoulos]

I don't recal finding anything similar to MySQL's password() (quote handy if you ask 
me). But if you look under the contrib directory of your source tree you'll find a 
pgcrypto directory. Compile and install the functions defined in there.
The substitute which worked in my case was: 
encode(digest('text_i_want_to_encode','sha1'),'hex'); It is not the same but it is a 
1-way hashing of a string (IIRC password() is 1-way)

cheers,
thalis


On Sun, 15 Jul 2001 [EMAIL PROTECTED] wrote:

> I am looking for a postgresql PASSWORD() function that
> produces hashes compatible with MySQL's implementation.
>  
> I am converting from MySQL and I know of no other way to
> use the passwords I have in the old database other than
> having a compatible PASSWORD() function.
>  
> I have searched around for one quite a bit but could not find
> one.  Does anyone know if someone has written something
> to do this already?  If so, where I can get it from?
>  
> Thanks in advance,
> Jason DiCioccio
> 
> 
> 
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
> 


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [GENERAL] Password authentication failed for user

[Michael Fuhr]

On Tue, Jun 07, 2005 at 11:17:52AM -0400, Robert Fitzpatrick wrote:
>
> I have a database that is used every day for the past year and all of a
> sudden, this morning, I get a report that a user cannot login. I have
> doubled checked the pg_hba.conf file, which has not been changed in
> several months. But only this one user even after resetting the
> password, any other user works fine and if I update the pg_hba.conf file
> to trust that user, it works. What can cause this? I don't know if I
> should post by pg_hba.conf file here, but like I said, nothing has
> changed in several months and this problem just appeared today.

Apparently something has changed -- the question is what?  If nothing
on the server, what about on the user's machine?  When was the last
time it was known for certain to have worked?

What method were you using before you changed it to "trust"?  If
you change it back, can you log in as the user from someplace that
works for other users?  Can the user in question log in as any other
user from wherever his or her own account is failing?  What error
shows up in the server's logs?

Are you restricting logins by IP address?  If so, has the user's
IP address changed?

It might be useful to see the contents of pg_hba.conf.

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [GENERAL] Password safe web application with postgre

[Allan Kamau]

Hi Bohdan,
Is your web applications for use with PostgreSQL server administration 
where you would like users to supply their login credentials for 
PostgreSQL so that their actions within the db can be limited by the 
fine gain privileges assigned to them?


If it is not then you may want to maybe remodel your solution so that 
your uses may share a common DB login whose login details 
(username,password and server host name etc) are stored/contained within 
your web application hosted on the server.
Then you supply your users with other username/password which will only 
be known by your web application and not the PostgreSQL login. When your 
users wish to use your web application, they will login with their 
username/password for the web application which your web application 
should verify (by means you see fit). The web application can now login 
(using the PostgreSQL credentials) to the DB on behalf of the user(s).
Using a shared login has the following advantages, you only need only 
one login for all your users. Which means you only need administer one 
login. And this gives you the option to use DB connection pooling (this 
is an application solution). Creating connections is an expensive 
process and should be done only when necessary.


Allan.

Bohdan Linda wrote:

Hello,

I have the following problem. A multiuser app has authentization and
authorization done based on pgsql.

The frontend is web based so it is stateless; it is connecting to database
on every get/post. There is also a requirement that the user is
transparently logged in for some period of time.

Tha most easy way is to store login credentials into the session. The
drawback is that session is stored in file, so the credentials are
readable. I want to avoid it. 


My first step was hashing the password with the same mechanizm as pgsql
does, but I am not able to pass it to the server. I did some research with
mighty google and found reply by Tom Lane:

"No, you need to put the plain text of the password into the connInfo.
Knowing the md5 doesn't prove you know the password. "

Thus the next logical step is keeping sessions in servers memory rather
than files. Memory dump could compromise it, but this is acceptable risk.

I would like to ask you, if someone had solved this problem is some more
elegant way.

Thank you,
Bohdan 

  



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general