.pgpass file and unix domain sockets
The documentation for the .pgpass file seems to be incorrect with respect to
unix domain sockets.
There's also a user comment saying that:
http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html
The documentation suggests that the hostname part of .pgpass can be set to
"localhost" to allow for automatic unix domain socket authentication. This
doesn't seem to work. Instead you have to set the directory of the socket as
the hostname part.
If this was never supposed to actually work as described, I'll submit a doc
patch that also explains in more detail how to use .pgpass for unix sockets.
Joachim
Joachim Wieland <joe@mcknight.de> writes:
The documentation suggests that the hostname part of .pgpass can be set to
"localhost" to allow for automatic unix domain socket authentication. This
doesn't seem to work. Instead you have to set the directory of the socket as
the hostname part.
It looks to me like if you don't specify the host in the connection request,
then "localhost" is indeed used to search .pgpass with. *However*, if
you specify a socket path in pghost, then that's what's used.
I'm not sure if that's a bug or not. Arguably, different socket paths
might point to different servers for which you need different passwords.
If we did want unix-socket connections to search for "localhost"
regardless of socket path, it'd be a simple change (change the order of
operations in connectOptions2). But maybe the code is right and we
should fix the documentation. Or maybe this whole notion of using
"localhost" is bogus and we should always use the socket path.
regards, tom lane
On Wed, May 10, 2006 at 09:34:38PM -0400, Tom Lane wrote:
I'm not sure if that's a bug or not. Arguably, different socket paths
might point to different servers for which you need different passwords.
If we did want unix-socket connections to search for "localhost"
regardless of socket path, it'd be a simple change (change the order of
operations in connectOptions2). But maybe the code is right and we
should fix the documentation. Or maybe this whole notion of using
"localhost" is bogus and we should always use the socket path.
Maybe something like "unix:*" would match all sockets and "unix:/tmp"
would match just that one. Or maybe just allow the special string
"unix:" match any socket and leave the rest alone.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
hackers - any opinions?
The biggest downside would be that a pgpass file would be version
specific for this feature. The badness of this is somewhat mitigated by
the ability we now have to specify an alternative pgpassfile location.
cheers
andrew
-------- Original Message --------
Subject: Re: [PATCHES] .pgpass file and unix domain sockets
Date: Tue, 16 May 2006 12:16:53 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
CC: Joachim Wieland <joe@mcknight.de>, pgsql-patches@postgresql.org
References: <20060516122554.GA4009@mcknight.de>
<11676.1147787022@sss.pgh.pa.us> <4469F499.1040002@dunslane.net>
<13302.1147795016@sss.pgh.pa.us> <4469FA5A.3090504@dunslane.net>
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Personally I wouldn't object to making it match "localhost" in all
cases. That's what the documentation says, and the use-case for
doing something more complicated seems pretty thin.
I almost agree. If anything, I'd prefer to provide for an explicit entry
covering all Unix Domain sockets - it took me by some surprise to find a
while back that "localhost" covers that case - it seems a mismatch with
how pg_hba.conf works.
Well, that'd break existing .pgpass files (unless we match localhost
too, which seems to defeat the purpose). But maybe it's worth doing
for consistency's sake. I think we should bring it up on a more
widely read list than -patches if you want to propose a
non-backwards-compatible change ...
Import Notes
Resolved by subject fallback
Uh, why wouldn't we allow "localhost" to match the default unix domain
socket name, as well as an empty hostname? If you specify a non-default
location, you then have to specify the full path.
---------------------------------------------------------------------------
Andrew Dunstan wrote:
hackers - any opinions?
The biggest downside would be that a pgpass file would be version
specific for this feature. The badness of this is somewhat mitigated by
the ability we now have to specify an alternative pgpassfile location.cheers
andrew
-------- Original Message --------
Subject: Re: [PATCHES] .pgpass file and unix domain sockets
Date: Tue, 16 May 2006 12:16:53 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
CC: Joachim Wieland <joe@mcknight.de>, pgsql-patches@postgresql.org
References: <20060516122554.GA4009@mcknight.de>
<11676.1147787022@sss.pgh.pa.us> <4469F499.1040002@dunslane.net>
<13302.1147795016@sss.pgh.pa.us> <4469FA5A.3090504@dunslane.net>Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Personally I wouldn't object to making it match "localhost" in all
cases. That's what the documentation says, and the use-case for
doing something more complicated seems pretty thin.I almost agree. If anything, I'd prefer to provide for an explicit entry
covering all Unix Domain sockets - it took me by some surprise to find a
while back that "localhost" covers that case - it seems a mismatch with
how pg_hba.conf works.Well, that'd break existing .pgpass files (unless we match localhost
too, which seems to defeat the purpose). But maybe it's worth doing
for consistency's sake. I think we should bring it up on a more
widely read list than -patches if you want to propose a
non-backwards-compatible change ...---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
I have implemented the idea I listed below, patch attached.
---------------------------------------------------------------------------
Bruce Momjian wrote:
Uh, why wouldn't we allow "localhost" to match the default unix domain
socket name, as well as an empty hostname? If you specify a non-default
location, you then have to specify the full path.---------------------------------------------------------------------------
Andrew Dunstan wrote:
hackers - any opinions?
The biggest downside would be that a pgpass file would be version
specific for this feature. The badness of this is somewhat mitigated by
the ability we now have to specify an alternative pgpassfile location.cheers
andrew
-------- Original Message --------
Subject: Re: [PATCHES] .pgpass file and unix domain sockets
Date: Tue, 16 May 2006 12:16:53 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
CC: Joachim Wieland <joe@mcknight.de>, pgsql-patches@postgresql.org
References: <20060516122554.GA4009@mcknight.de>
<11676.1147787022@sss.pgh.pa.us> <4469F499.1040002@dunslane.net>
<13302.1147795016@sss.pgh.pa.us> <4469FA5A.3090504@dunslane.net>Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Personally I wouldn't object to making it match "localhost" in all
cases. That's what the documentation says, and the use-case for
doing something more complicated seems pretty thin.I almost agree. If anything, I'd prefer to provide for an explicit entry
covering all Unix Domain sockets - it took me by some surprise to find a
while back that "localhost" covers that case - it seems a mismatch with
how pg_hba.conf works.Well, that'd break existing .pgpass files (unless we match localhost
too, which seems to defeat the purpose). But maybe it's worth doing
for consistency's sake. I think we should bring it up on a more
widely read list than -patches if you want to propose a
non-backwards-compatible change ...---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly--
Bruce Momjian http://candle.pha.pa.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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/pgpatches/pgpasstext/plainDownload
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.208
diff -c -c -r1.208 libpq.sgml
*** doc/src/sgml/libpq.sgml 6 May 2006 16:25:11 -0000 1.208
--- doc/src/sgml/libpq.sgml 17 May 2006 01:52:40 -0000
***************
*** 4000,4008 ****
entries first when you are using wildcards.)
If an entry needs to contain <literal>:</literal> or
<literal>\</literal>, escape this character with <literal>\</literal>.
! A hostname of <literal>localhost</> matches both <literal>host</> (TCP)
! and <literal>local</> (Unix domain socket) connections coming from the
! local machine.
</para>
<para>
--- 4000,4008 ----
entries first when you are using wildcards.)
If an entry needs to contain <literal>:</literal> or
<literal>\</literal>, escape this character with <literal>\</literal>.
! A hostname of <literal>localhost</> matches both TCP <literal>host</> (hostname <literal>localhost</>)
! and Unix domain socket <literal>local</> (<literal>pghost</> empty or the default socket directory)
! connections coming from the local machine.
</para>
<para>
Index: src/interfaces/libpq/fe-connect.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.328
diff -c -c -r1.328 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 14 Mar 2006 22:48:23 -0000 1.328
--- src/interfaces/libpq/fe-connect.c 17 May 2006 01:52:59 -0000
***************
*** 3106,3114 ****
--- 3106,3129 ----
if (username == NULL || strlen(username) == 0)
return NULL;
+ /* 'localhost' matches pghost of '' or the default socket directory */
if (hostname == NULL)
hostname = DefaultHost;
+ else if (is_absolute_path(hostname))
+ {
+ char canon_host[MAXPGPATH];
+ char canon_def_socket[MAXPGPATH];
+
+ StrNCpy(canon_host, hostname, MAXPGPATH);
+ StrNCpy(canon_def_socket, DEFAULT_PGSOCKET_DIR, MAXPGPATH);
+ canonicalize_path(canon_host);
+ canonicalize_path(canon_def_socket);
+
+ if (strcmp(canon_host, canon_def_socket) == 0)
+ hostname = DefaultHost;
+ }
+
if (port == NULL)
port = DEF_PGPORT_STR;
Patch applied. It will appear in 8.2.
---------------------------------------------------------------------------
Bruce Momjian wrote:
I have implemented the idea I listed below, patch attached.
---------------------------------------------------------------------------
Bruce Momjian wrote:
Uh, why wouldn't we allow "localhost" to match the default unix domain
socket name, as well as an empty hostname? If you specify a non-default
location, you then have to specify the full path.---------------------------------------------------------------------------
Andrew Dunstan wrote:
hackers - any opinions?
The biggest downside would be that a pgpass file would be version
specific for this feature. The badness of this is somewhat mitigated by
the ability we now have to specify an alternative pgpassfile location.cheers
andrew
-------- Original Message --------
Subject: Re: [PATCHES] .pgpass file and unix domain sockets
Date: Tue, 16 May 2006 12:16:53 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
CC: Joachim Wieland <joe@mcknight.de>, pgsql-patches@postgresql.org
References: <20060516122554.GA4009@mcknight.de>
<11676.1147787022@sss.pgh.pa.us> <4469F499.1040002@dunslane.net>
<13302.1147795016@sss.pgh.pa.us> <4469FA5A.3090504@dunslane.net>Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Personally I wouldn't object to making it match "localhost" in all
cases. That's what the documentation says, and the use-case for
doing something more complicated seems pretty thin.I almost agree. If anything, I'd prefer to provide for an explicit entry
covering all Unix Domain sockets - it took me by some surprise to find a
while back that "localhost" covers that case - it seems a mismatch with
how pg_hba.conf works.Well, that'd break existing .pgpass files (unless we match localhost
too, which seems to defeat the purpose). But maybe it's worth doing
for consistency's sake. I think we should bring it up on a more
widely read list than -patches if you want to propose a
non-backwards-compatible change ...---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly--
Bruce Momjian http://candle.pha.pa.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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/libpq.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.208 diff -c -c -r1.208 libpq.sgml *** doc/src/sgml/libpq.sgml 6 May 2006 16:25:11 -0000 1.208 --- doc/src/sgml/libpq.sgml 17 May 2006 01:52:40 -0000 *************** *** 4000,4008 **** entries first when you are using wildcards.) If an entry needs to contain <literal>:</literal> or <literal>\</literal>, escape this character with <literal>\</literal>. ! A hostname of <literal>localhost</> matches both <literal>host</> (TCP) ! and <literal>local</> (Unix domain socket) connections coming from the ! local machine. </para><para> --- 4000,4008 ---- entries first when you are using wildcards.) If an entry needs to contain <literal>:</literal> or <literal>\</literal>, escape this character with <literal>\</literal>. ! A hostname of <literal>localhost</> matches both TCP <literal>host</> (hostname <literal>localhost</>) ! and Unix domain socket <literal>local</> (<literal>pghost</> empty or the default socket directory) ! connections coming from the local machine. </para><para> Index: src/interfaces/libpq/fe-connect.c =================================================================== RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.328 diff -c -c -r1.328 fe-connect.c *** src/interfaces/libpq/fe-connect.c 14 Mar 2006 22:48:23 -0000 1.328 --- src/interfaces/libpq/fe-connect.c 17 May 2006 01:52:59 -0000 *************** *** 3106,3114 **** --- 3106,3129 ---- if (username == NULL || strlen(username) == 0) return NULL;+ /* 'localhost' matches pghost of '' or the default socket directory */ if (hostname == NULL) hostname = DefaultHost; + else if (is_absolute_path(hostname)) + { + char canon_host[MAXPGPATH]; + char canon_def_socket[MAXPGPATH]; + + StrNCpy(canon_host, hostname, MAXPGPATH); + StrNCpy(canon_def_socket, DEFAULT_PGSOCKET_DIR, MAXPGPATH);+ canonicalize_path(canon_host); + canonicalize_path(canon_def_socket); + + if (strcmp(canon_host, canon_def_socket) == 0) + hostname = DefaultHost; + } + if (port == NULL) port = DEF_PGPORT_STR;
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +