Matt,
* Desidero (desid...@gmail.com) wrote:
> I agree that it would be better for us to use something other than LDAP,
If you happen to be using Active Directory, then you should really be
using Kerberos-based auth instead. AD includes both LDAP and a KDC and
the LDAP half is really *not* the w
Tom Lane wrote:
> On many platforms, it's possible for other users to see the environment
> variables of a process. So PGPASSWORD is really quite insecure.
As said in https://www.postgresql.org/docs/current/static/libpq-envars.html
"PGPASSWORD behaves the same as the password connecti
"Daniel Verite" writes:
> Desidero wrote:
>> When attempting to use something like an anonymous pipe for a
>> passfile, psql throws an error stating that it only accepts plain files
> So the script doing that has access to the password(s) in clear text.
> Can't it instead push the password
Desidero wrote:
> When attempting to use something like an anonymous pipe for a
> passfile, psql throws an error stating that it only accepts plain files
So the script doing that has access to the password(s) in clear text.
Can't it instead push the password into the PGPASSWORD
environmen
On 10/19/2017 09:20 AM, Desidero wrote:
> I agree that it would be better for us to use something other than
> LDAP, but unfortunately it's difficult to convince the powers that be
> that we can/should use something else that they are not yet prepared
> to properly manage/audit. We are working to
I agree that it would be better for us to use something other than LDAP,
but unfortunately it's difficult to convince the powers that be that we
can/should use something else that they are not yet prepared to properly
manage/audit. We are working towards it, but we're not there yet. It's not
really
On 10/19/2017 02:12 AM, Tom Lane wrote:
> Desidero writes:
>> I’m running into problems with the restriction on pgpass file types. When
>> attempting to use something like an anonymous pipe for a passfile, psql
>> throws an error stating that it only accepts plain files.
>> ...
>> Does anyone kn
Desidero writes:
> I’m running into problems with the restriction on pgpass file types. When
> attempting to use something like an anonymous pipe for a passfile, psql
> throws an error stating that it only accepts plain files.
> ...
> Does anyone know why it’s set up to avoid using things like ano
Hello,
I’m running into problems with the restriction on pgpass file types. When
attempting to use something like an anonymous pipe for a passfile, psql
throws an error stating that it only accepts plain files. If it matters,
I'm trying to use that so I can pass a decrypted pgpassfile into postg
On 9/15/15 1:48 AM, Ben Chobot wrote:
> We're in a situation where we would like to take advantage of the pgpass
> hostname field to determine which password gets used. For example:
>
> psql -h prod-server -d foo # should use the prod password
> psql -h beta-server -d foo # should use the beta pa
On 9/15/15 10:32 AM, Ben Chobot wrote:
On Sep 15, 2015, at 12:27 AM, Jim Nasby wrote:
On 9/15/15 12:48 AM, Ben Chobot wrote:
We're in a situation where we would like to take advantage of the pgpass
hostname field to determine which password gets used. For example:
psql -h prod-server -d foo
On Sep 15, 2015, at 12:27 AM, Jim Nasby wrote:
>
> On 9/15/15 12:48 AM, Ben Chobot wrote:
>> We're in a situation where we would like to take advantage of the pgpass
>> hostname field to determine which password gets used. For example:
>>
>> psql -h prod-server -d foo # should use the prod pass
On 9/15/15 12:48 AM, Ben Chobot wrote:
We're in a situation where we would like to take advantage of the pgpass
hostname field to determine which password gets used. For example:
psql -h prod-server -d foo # should use the prod password
psql -h beta-server -d foo # should use the beta password
We're in a situation where we would like to take advantage of the pgpass
hostname field to determine which password gets used. For example:
psql -h prod-server -d foo # should use the prod password
psql -h beta-server -d foo # should use the beta password
This would *seem* to be simple, just put
In case someone is facing the same problem again, solution is to add * in
.pgpass in place of ip address.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/pgpass-being-ignored-tp5760421p5815268.html
Sent from the PostgreSQL - general mailing list archive at Nabble.co
On Sat, Jun 22, 2013 at 12:19 AM, Stephen Rasku wrote:
> I am trying to write a script that will create and populate a
> database. I don't want to enter a password every time so I want to
> use a .pgpass file. It has the correct permissions:
>
> $ ls -l $PGPASSFILE
> -rw--- 1 Stephe
On 06/24/2013 11:36 PM, Frank Broniewski wrote:
However, when I call createdb, it fails:
$ createdb -h 192.168.1.4 -U postgres --no-password
JobSearch
createdb: could not connect to database postgres:
fe_sendauth: no
password supplied
Hi,
However, when I call createdb, it fails:
$ createdb -h 192.168.1.4 -U postgres --no-password JobSearch
createdb: could not connect to database postgres:
fe_sendauth: no
password supplied
Hi,
isn't your --no-password switch preventing this
On 06/24/13 10:24, Rebecca Clarke wrote:
> I could be wrong, but shouldn't the owner of .pgpass be postgres?
The owner of ~/.pgpass is whoever owns ~ (the home directory of that user).
And ~/.pgpass must have permissions 0600 in order for libpq to actually
use it.
Jan
>
>
> On Mon, Jun 24,
On 13-06-21 06:19 PM, Stephen Rasku wrote:
I am trying to write a script that will create and populate a
database. I don't want to enter a password every time so I want to
use a .pgpass file. It has the correct permissions:
$ ls -l $PGPASSFILE
-rw--- 1 Stephen staff 43 21 Jun
I could be wrong, but shouldn't the owner of .pgpass be postgres?
On Mon, Jun 24, 2013 at 3:17 PM, Ziggy Skalski wrote:
> On 13-06-21 06:19 PM, Stephen Rasku wrote:
>
>> I am trying to write a script that will create and populate a
>> database. I don't want to enter a password every time so I w
On 06/21/2013 04:29 PM, Stephen Rasku wrote:
On Fri, Jun 21, 2013 at 3:41 PM, Adrian Klaver wrote:
First are you running the script from the location with .pgpass?
I wasn't but I copied the .pgpass into the local directory and I get
the same results. The correct location is actually in the
On Fri, Jun 21, 2013 at 3:41 PM, Adrian Klaver wrote:
>
> First are you running the script from the location with .pgpass?
I wasn't but I copied the .pgpass into the local directory and I get
the same results. The correct location is actually in the home
directory.
> Second you are doing a crea
I am trying to write a script that will create and populate a
database. I don't want to enter a password every time so I want to
use a .pgpass file. It has the correct permissions:
$ ls -l $PGPASSFILE
-rw--- 1 Stephen staff 43 21 Jun 14:48 /Users/Stephen/.pgpass
However, when I c
On Fri, Jun 21, 2013 at 3:33 PM, Raymond O'Donnell wrote:
>
> What's in your server's pg_hba.conf file?
# TYPE DATABASEUSERCIDR-ADDRESSMETHOD
#@remove-line-for-nolocal@# "local" is for Unix domain socket connections only
local all all
On 06/21/2013 03:25 PM, Stephen Rasku wrote:
I am trying to write a script that will create and populate a
database. I don't want to enter a password every time so I want to
use a .pgpass file. It has the correct permissions:
$ ls -l $PGPASSFILE
-rw--- 1 Stephen staff 43 21 Ju
On 21/06/2013 23:25, Stephen Rasku wrote:
> I am trying to write a script that will create and populate a
> database. I don't want to enter a password every time so I want to
> use a .pgpass file. It has the correct permissions:
>
> $ ls -l $PGPASSFILE
> -rw--- 1 Stephen staff 43
I am trying to write a script that will create and populate a
database. I don't want to enter a password every time so I want to
use a .pgpass file. It has the correct permissions:
$ ls -l $PGPASSFILE
-rw--- 1 Stephen staff 43 21 Jun 14:48 /Users/Stephen/.pgpass
However, when I c
On 2013-02-05, Scott Mead wrote:
> I would love to see pgpass storing encrypted stuff here, that'd be great...
> in the meantime...
whatever it stores will, of necessity, be sufficient to grant access to the
postgres database, libpq could be modified to use MD5 hashed passwords
in that file salt
* Shaun Thomas (stho...@optionshouse.com) wrote:
> On 02/05/2013 03:40 PM, Stephen Frost wrote:
> >You need to register the server w/ AD by creating a principal for it and
> >then exporting the princ (shared secret between the KDC and the server)
> >and then loading it on the server.
>
> That look
On 02/05/2013 03:40 PM, Stephen Frost wrote:
You need to register the server w/ AD by creating a principal for it and
then exporting the princ (shared secret between the KDC and the server)
and then loading it on the server.
That looks like something our Windows admins will have to do since th
* Shaun Thomas (stho...@optionshouse.com) wrote:
> psql: GSSAPI continuation error: Unspecified GSS failure. Minor
> code may provide more information
> GSSAPI continuation error: Server not found in Kerberos database
>
> Not extremely useful.
You need to register the server w/ AD by creating a
On 02/05/2013 02:58 PM, Scott Marlowe wrote:
Why are you using LDAP and passing passwords for access to insecure
systems?
We're trying not to. That's kind of my point. Now, I'd love to spend
another few days learning yet another auth mechanism (kerberos) but I
was trying to avoid it.
As it
On Tue, Feb 5, 2013 at 12:07 PM, Shaun Thomas wrote:
> On 02/05/2013 12:44 PM, Scott Marlowe wrote:
>
>> Stop. If you want secure setups you don't hand out root access to
>> lots of people. Trying to then make it secure is like closing the
>> barn door after the horse has left.
>
>
> I guess you
Shaun,
* Shaun Thomas (stho...@optionshouse.com) wrote:
> We're wanting to implement a more secure password policy, and so
> have considered switching to LDAP/Active Directory for passwords.
Don't use the LDAP side of AD, use the Kerberos side. Using LDAP for
auth against AD is terrible and is o
On Tue, Feb 5, 2013 at 1:57 PM, Scott Mead wrote:
>
>
> I would love to see pgpass storing encrypted stuff here, that'd be
> great... in the meantime...
>
>
I would suggest going one step further, and making encrypted pgpass
authorization something that has to be specifically enabled in pg_hba.co
On 02/05/2013 12:44 PM, Scott Marlowe wrote:
Stop. If you want secure setups you don't hand out root access to
lots of people. Trying to then make it secure is like closing the
barn door after the horse has left.
I guess you missed the part where I said I thought we should lock root
down be
On Tue, Feb 5, 2013 at 11:53 AM, Joshua D. Drake wrote:
>
> On 02/05/2013 10:44 AM, Scott Marlowe wrote:
>>
>>
>> On Tue, Feb 5, 2013 at 10:15 AM, Shaun Thomas
>> wrote:
>>>
>>> Hey folks,
>>>
>>> We're wanting to implement a more secure password policy, and so have
>>> considered switching to LD
On Tue, Feb 5, 2013 at 12:15 PM, Shaun Thomas wrote:
> Hey folks,
>
> We're wanting to implement a more secure password policy, and so have
> considered switching to LDAP/Active Directory for passwords. Normally, this
> would be fine, but for two things:
>
> 1. Tons of our devs use .pgpass files t
On 02/05/2013 10:44 AM, Scott Marlowe wrote:
On Tue, Feb 5, 2013 at 10:15 AM, Shaun Thomas wrote:
Hey folks,
We're wanting to implement a more secure password policy, and so have
considered switching to LDAP/Active Directory for passwords. Normally, this
would be fine, but for two things:
1
On Tue, Feb 5, 2013 at 10:15 AM, Shaun Thomas wrote:
> Hey folks,
>
> We're wanting to implement a more secure password policy, and so have
> considered switching to LDAP/Active Directory for passwords. Normally, this
> would be fine, but for two things:
>
> 1. Tons of our devs use .pgpass files t
Hey folks,
We're wanting to implement a more secure password policy, and so have
considered switching to LDAP/Active Directory for passwords. Normally,
this would be fine, but for two things:
1. Tons of our devs use .pgpass files to connect everywhere.
2. Several devs have root access to vari
Hi Ben
I had saved the .pgpass file in my home directory /home/user/.pgpass which
works when I'm logged in as user. However, in order for me to use Slony, I
had to be logged in as postgres user.
I installed strace and ran my pg_dump test and found that it actually looks
for the .pgpass file in /va
On May 4, 2012, at 9:30 AM, Rebecca Clarke wrote:
> I do not want to touch the pg_hba.conf so I have generated the .pgpass file.
> The permissions is set to 600, and I have correctly inputted the details into
> .pgpass, there are no leading spaces.
>
> myhostname:myport:*:postgres:mypassword
>
Rebecca Clarke writes:
> I'm having password issues with slony.
> I have roamed the net for a solution and the way to fix it is to use the
> .pgpass file or change pg_hba.conf to accept trusted connections.
> I do not want to touch the pg_hba.conf so I have generated the .pgpass file.
Reasonable.
Hi
Apologies in advance if this is the wrong place to ask.
I have Postres 8.4 and I am setting up replication with Slony.
I'm having password issues with slony.
I have roamed the net for a solution and the way to fix it is to use the
.pgpass file or change pg_hba.conf to accept trusted connection
Dah, left out the port.
On Fri, Apr 8, 2011 at 10:36 PM, Yang Zhang wrote:
> I'm using the postgresql 8.4.7 in Ubuntu 10.04, and I'm trying to use
> .pgpass documented here:
>
> http://www.postgresql.org/docs/8.4/interactive/libpq-pgpass.html
>
> I have a ~/.pgpass with 600 perms containing:
>
>
I'm using the postgresql 8.4.7 in Ubuntu 10.04, and I'm trying to use
.pgpass documented here:
http://www.postgresql.org/docs/8.4/interactive/libpq-pgpass.html
I have a ~/.pgpass with 600 perms containing:
myhostname.com:yang:yang:mypassword
However, it doesn't seem to get picked up by psql -h
On Tue, Aug 16, 2005 at 04:54:15PM +0100, Oluwatope Akinniyi wrote:
> On Fedora as:
> 192.168.0.253:5432:hms:sysdba:x
> where hms is the database and sysdba the username;
>
> I have a the ~/.pgpass inside the home of user tope (i.e. /home/tope).
> I tried with
>
> $ psql
I wonder if you sho
>
>
>>> > On Fedora: wrong file permissions?
>>> > Btw.: ~/.pgpass is only supported in 7.3 and later.
>>
>>
>>
>> Thanks.
>>
>> The permission is 0600 on Fedora. But must the file
>> (~/.pgpass) be owned by postgres? Also what could explain the
>> reason why it is not working on Windows X
> > On Fedora: wrong file permissions?
> > Btw.: ~/.pgpass is only supported in 7.3 and later.
>
> Thanks.
>
> The permission is 0600 on Fedora. But must the file
> (~/.pgpass) be owned by postgres? Also what could explain the
> reason why it is not working on Windows XP where permission
> is
Andreas wrote:
> On Fedora: wrong file permissions?
> Btw.: ~/.pgpass is only supported in 7.3 and later.
Thanks.
The permission is 0600 on Fedora. But must the file (~/.pgpass) be owned by
postgres? Also what could explain the reason why it is not working on Windows
XP where permission is no
Oluwatope Akinniyi <[EMAIL PROTECTED]> schrieb:
> Martijn van Oosterhout wrote:
>
> >> It's ~/.pgpass the dot is important.
> >
> >
>
> Thanks. Just a typo error in the mail.
>
> I did put the dot in the file name. The file on Fedora is ~/.pgpass and on
> Windows it is in %APPDATA%/postgre
Martijn van Oosterhout wrote:
>> It's ~/.pgpass the dot is important.
>
>
Thanks. Just a typo error in the mail.
I did put the dot in the file name. The file on Fedora is ~/.pgpass and on
Windows it is in %APPDATA%/postgresql as pgpass.conf.
It did not work in Windows and Fedora.
Tope A
On Sun, Aug 14, 2005 at 08:36:17PM +0100, Oluwatope Akinniyi wrote:
> I tried the password file and could not get it to work on both Windows
> XP and Fedora Core 4.
>
> ~/pgpass permission is 0600 on Fedora and I tested using psql and
> pg_dump commands. The two commands prompted for password and
I tried the password file and could not get it to work on both Windows
XP and Fedora Core 4.
~/pgpass permission is 0600 on Fedora and I tested using psql and
pg_dump commands. The two commands prompted for password and target
database which I expected should not be.
Please, I seek for clarificat
56 matches
Mail list logo
