server authentication over Unix-domain sockets
It has been discussed several times in the past that there is no way for
a client to authenticate a server over Unix-domain sockets. So
depending on circumstances, a local user could easily insert his own
server and collect passwords and data. Suggestions for possible
remedies included:
You can put the socket file in a sufficiently write-protected directory.
But that would strongly deviate from the default setup, and anyway the
client still cannot readily verify that the server is the right one.
You can also run SSL over Unix-domain sockets. This is currently
disabled in the code, but it would work just fine. But it's obviously
kind of awkward, and the connection overhead was noticeable in tests.
Then it was suggested to use the local "ident" mechanism in reverse, so
the client could verify what user the server runs under. I have
implemented a prototype of this. You can put, e.g.,
requirepeer=postgres
into the connection parameters, and the connection will be rejected
unless the process at the other end of the socket is running as
postgres.
The patch needs some portability work and possible refactoring because
of that, but before I embark on that, comments on the concept?
Attachments:
serverauth-requirepeer.patchtext/x-patch; charset=UTF-8; name=serverauth-requirepeer.patchDownload
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index be788e9..400a6ae 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -449,6 +449,28 @@
</listitem>
</varlistentry>
+ <varlistentry id="libpq-connect-requirepeer" xreflabel="requirepeer">
+ <term><literal>requirepeer</literal></term>
+ <listitem>
+ <para>
+ For Unix-domain socket connections, if this parameter is
+ set, the client checks at the beginning of the connection
+ that the server process runs under the specified user name,
+ otherwise the connection is aborted with an error. This
+ parameter can be used to achieve the kind of server
+ authentication that SSL certificates achieve on TCP/IP
+ connections. (Note that if the Unix-domain socket is
+ in <filename>/tmp</filename> or another publically writable
+ location, any user could start a server there. Use this
+ parameter to ensure that you are connected to a server run
+ by a trusted user,
+ e.g., <literal>requirepeer=postgres</literal>.) This
+ option is only supported on some platforms, currently
+ Linux, FreeBSD, NetBSD, OpenBSD, BSD/OS, and Solaris.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="libpq-connect-krbsrvname" xreflabel="krbsrvname">
<term><literal>krbsrvname</literal></term>
<listitem>
@@ -6082,6 +6104,16 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
<listitem>
<para>
<indexterm>
+ <primary><envar>PGREQUIREPEER</envar></primary>
+ </indexterm>
+ <envar>PGREQUIREPEER</envar> behaves the same as the <xref
+ linkend="libpq-connect-requirepeer"> connection parameter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <indexterm>
<primary><envar>PGKRBSRVNAME</envar></primary>
</indexterm>
<envar>PGKRBSRVNAME</envar> behaves the same as the <xref
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index ab6cc08..9b8de26 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -214,6 +214,9 @@ static const PQconninfoOption PQconninfoOptions[] = {
{"sslcrl", "PGSSLCRL", NULL, NULL,
"SSL-Revocation-List", "", 64},
+ {"requirepeer", "PGREQUIREPEER", NULL, NULL,
+ "Require-Peer", "", 10},
+
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
/* Kerberos and GSSAPI authentication support specifying the service name */
{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
@@ -572,6 +575,8 @@ fillPGconn(PGconn *conn, PQconninfoOption *connOptions)
conn->sslmode = strdup("require");
}
#endif
+ tmp = conninfo_getval(connOptions, "requirepeer");
+ conn->requirepeer = tmp ? strdup(tmp) : NULL;
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
tmp = conninfo_getval(connOptions, "krbsrvname");
conn->krbsrvname = tmp ? strdup(tmp) : NULL;
@@ -1501,6 +1506,44 @@ keep_going: /* We will come back to here until there is
char *startpacket;
int packetlen;
+ // TODO: currently Linux-only code, needs to be made
+ // portable; see backend/libpq/auth.c
+ if (conn->requirepeer)
+ {
+ struct ucred peercred;
+ ACCEPT_TYPE_ARG3 so_len = sizeof(peercred);
+ struct passwd *pass;
+
+ errno = 0;
+ if (getsockopt(conn->sock, SOL_SOCKET, SO_PEERCRED, &peercred, &so_len) != 0 ||
+ so_len != sizeof(peercred))
+ {
+ /* We didn't get a valid credentials struct. */
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("could not get peer credentials: %s\n"),
+ SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
+ goto error_return;
+ }
+
+ pass = getpwuid(peercred.uid);
+
+ if (pass == NULL)
+ {
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("local user with ID %d does not exist\n"),
+ (int) peercred.uid);
+ goto error_return;
+ }
+
+ if (strcmp(pass->pw_name, conn->requirepeer) != 0)
+ {
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("requirepeer failed (actual: %s != required: %s)\n"),
+ pass->pw_name, conn->requirepeer);
+ goto error_return;
+ }
+ }
+
#ifdef USE_SSL
/*
@@ -2300,6 +2343,8 @@ freePGconn(PGconn *conn)
free(conn->sslrootcert);
if (conn->sslcrl)
free(conn->sslcrl);
+ if (conn->requirepeer)
+ free(conn->requirepeer);
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
if (conn->krbsrvname)
free(conn->krbsrvname);
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index e88b3ec..afb15f0 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -305,6 +305,7 @@ struct pg_conn
char *sslcert; /* client certificate filename */
char *sslrootcert; /* root certificate filename */
char *sslcrl; /* certificate revocation list filename */
+ char *requirepeer; /* required peer credentials for local sockets */
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
char *krbsrvname; /* Kerberos service name */
On Sun, May 30, 2010 at 13:00, Peter Eisentraut <peter_e@gmx.net> wrote:
It has been discussed several times in the past that there is no way for
a client to authenticate a server over Unix-domain sockets. So
depending on circumstances, a local user could easily insert his own
server and collect passwords and data. Suggestions for possible
remedies included:You can put the socket file in a sufficiently write-protected directory.
But that would strongly deviate from the default setup, and anyway the
client still cannot readily verify that the server is the right one.You can also run SSL over Unix-domain sockets. This is currently
disabled in the code, but it would work just fine. But it's obviously
kind of awkward, and the connection overhead was noticeable in tests.Then it was suggested to use the local "ident" mechanism in reverse, so
the client could verify what user the server runs under. I have
implemented a prototype of this. You can put, e.g.,requirepeer=postgres
into the connection parameters, and the connection will be rejected
unless the process at the other end of the socket is running as
postgres.The patch needs some portability work and possible refactoring because
of that, but before I embark on that, comments on the concept?--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Sun, May 30, 2010 at 13:00, Peter Eisentraut <peter_e@gmx.net> wrote:
It has been discussed several times in the past that there is no way for
a client to authenticate a server over Unix-domain sockets. So
depending on circumstances, a local user could easily insert his own
server and collect passwords and data. Suggestions for possible
remedies included:You can put the socket file in a sufficiently write-protected directory.
But that would strongly deviate from the default setup, and anyway the
client still cannot readily verify that the server is the right one.You can also run SSL over Unix-domain sockets. This is currently
disabled in the code, but it would work just fine. But it's obviously
kind of awkward, and the connection overhead was noticeable in tests.Then it was suggested to use the local "ident" mechanism in reverse, so
the client could verify what user the server runs under. I have
implemented a prototype of this. You can put, e.g.,requirepeer=postgres
into the connection parameters, and the connection will be rejected
unless the process at the other end of the socket is running as
postgres.The patch needs some portability work and possible refactoring because
of that, but before I embark on that, comments on the concept?
I like it. ISTM like something that would be very useful - an easy way
to get a fair amount of extra security in the case of local
connections, at almost zero cost. Just an "export
PGREQUIREPEER=postgres" in .profile goes a long way :-)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
* Peter Eisentraut (peter_e@gmx.net) wrote:
The patch needs some portability work and possible refactoring because
of that, but before I embark on that, comments on the concept?
I definitely like the idea but I dislike requiring the user to do
something to implement it. Thinking about how packagers might want to
use it, could we make it possible to build it defaulted to a specific
value (eg: 'postgres' on Debian) and allow users a way to override
and/or unset it?
Having the option wouldn't do much unless users know of it and use it
and it strikes that will very often not be the case.
I'm impartial towards whatever PG wants to do with the default, just so
long as packagers can override it and set it to something specific.
Also, to that end, it's got to be name-based. Exim in Debian did
something similar and actually tried to force a particular UID.. that
was horrid. :) On Debian, at least, the user is almost always
'postgres', but the UID will vary depending on exactly when the packages
were installed (before or after other system-user-creating packages).
Thanks,
Stephen
On Fri, Jun 11, 2010 at 14:07, Stephen Frost <sfrost@snowman.net> wrote:
* Peter Eisentraut (peter_e@gmx.net) wrote:
The patch needs some portability work and possible refactoring because
of that, but before I embark on that, comments on the concept?I definitely like the idea but I dislike requiring the user to do
something to implement it. Thinking about how packagers might want to
use it, could we make it possible to build it defaulted to a specific
value (eg: 'postgres' on Debian) and allow users a way to override
and/or unset it?
Well, even if we don't put that in, the packager could export a global
PGREQUIREPEER environment variable.
Having the option wouldn't do much unless users know of it and use it
and it strikes that will very often not be the case.I'm impartial towards whatever PG wants to do with the default, just so
long as packagers can override it and set it to something specific.
Also, to that end, it's got to be name-based. Exim in Debian did
something similar and actually tried to force a particular UID.. that
was horrid. :) On Debian, at least, the user is almost always
'postgres', but the UID will vary depending on exactly when the packages
were installed (before or after other system-user-creating packages).
Oh yes, absolutely name-based.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
* Magnus Hagander (magnus@hagander.net) wrote:
On Fri, Jun 11, 2010 at 14:07, Stephen Frost <sfrost@snowman.net> wrote:
I definitely like the idea but I dislike requiring the user to do
something to implement it. Thinking about how packagers might want to
use it, could we make it possible to build it defaulted to a specific
value (eg: 'postgres' on Debian) and allow users a way to override
and/or unset it?Well, even if we don't put that in, the packager could export a global
PGREQUIREPEER environment variable.
Yeahhhh, no, that's a crappy solution, sorry. :) I've been down that
road with people trying to monkey with /etc/bashrc; oh wait, not
everyone uses bash, and having every package screw with that stuff is
equally horrible. Admittedly, in this specific case, Debian could
implement what you're talking about in it's wrapper system, maybe, but I
still don't like it and if people don't use the wrapper (I can imagine
cases why that might happen, tho I havn't ever had to myself), they
wouldn't get the benefit..
Thanks,
Stephen
(2010/06/11 21:11), Stephen Frost wrote:
* Magnus Hagander (magnus@hagander.net) wrote:
On Fri, Jun 11, 2010 at 14:07, Stephen Frost<sfrost@snowman.net> wrote:
I definitely like the idea but I dislike requiring the user to do
something to implement it. Thinking about how packagers might want to
use it, could we make it possible to build it defaulted to a specific
value (eg: 'postgres' on Debian) and allow users a way to override
and/or unset it?Well, even if we don't put that in, the packager could export a global
PGREQUIREPEER environment variable.Yeahhhh, no, that's a crappy solution, sorry. :) I've been down that
road with people trying to monkey with /etc/bashrc; oh wait, not
everyone uses bash, and having every package screw with that stuff is
equally horrible. Admittedly, in this specific case, Debian could
implement what you're talking about in it's wrapper system, maybe, but I
still don't like it and if people don't use the wrapper (I can imagine
cases why that might happen, tho I havn't ever had to myself), they
wouldn't get the benefit..
Are you suggesting the packager enforces a certain unix user on the
installation time, although 'postgres' shall be used in most cases?
Let's back to the purpose of the feature.
In my understanding, it provides the client process the way to verity
user identifier of the server process before sending password.
Indeed, if we provide a default value of the "requirepeer" using
environment variable, the client process can override its own setting.
But is there any problem?
This option allows the client process to specify an expected user
identifier of the server process, then libpq closes the connection
if not matched.
Even if the default shall be given from the system default, the
client can provide an explicit alternative in the connection string.
Is there any fundamental differences to the environment variable?
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
On fre, 2010-06-11 at 08:07 -0400, Stephen Frost wrote:
Having the option wouldn't do much unless users know of it and use it
and it strikes that will very often not be the case.
That situation is the same as with SSL over TCP/IP with certificate
validation. I don't think we can make either of these the default
without risking breaking a lot of things.
I've checked on this patch.
As you described at the source code comments as follows,
it is not portable except for Linux due to the getsockopt() API.
+ // TODO: currently Linux-only code, needs to be made
+ // portable; see backend/libpq/auth.cI expect it shall be fixed (using the code come from ident_unix()?)
before committing.
I'd like to point out one other point.
It uses getpwuid() to translate a user identifier into a user name,
but it returns a pointer of the static variable within glibc.
So, it is not thread-safe. I recommend to use getpwnam_r() instead.
Except for the issue, it looks to me fine.
* The patch can be applied on the head of the git repository.
* We can build the code without any warnings/errors.
* It works as described in the documentation.
[kaigai@saba ~]$ php -r 'pg_connect("dbname=postgres requirepeer=xxxx");'
PHP Warning: pg_connect(): Unable to connect to PostgreSQL server: invalid connection option "requirepeer" in Command line code on line 1
=> Existing library, so not supported.
[kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \
php -r 'pg_connect("dbname=postgres requirepeer=xxxx");'
PHP Warning: pg_connect(): Unable to connect to PostgreSQL server: requirepeer failed (actual: kaigai != required: xxxx) in Command line code on line 1
LOG: incomplete startup packet
=> Patched library, so it prevent unexpected user-id of server process
[kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \
php -r 'pg_connect("dbname=postgres requirepeer=kaigai");'
=> Patched library, so it does not prevent anything for the expected user-id.
[kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \
php -r 'pg_connect("dbname=postgres");'
=> No "requirepeer", so it does not prevent anything.
[kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \
env PGREQUIREPEER=xyz php -r 'pg_connect("dbname=postgres");'
PHP Warning: pg_connect(): Unable to connect to PostgreSQL server: requirepeer failed (actual: kaigai != required: xyz) in Command line code on line 1
LOG: incomplete startup packet
=> PGREQUIREPEER environment variable, instead of "requirepeer" option. Same result.
[kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \
env PGREQUIREPEER=kaigai php -r 'pg_connect("dbname=postgres");'
=> PGREQUIREPEER environment variable, instead of "requirepeer" option. Same result.
Thanks,
(2010/05/30 20:00), Peter Eisentraut wrote:
It has been discussed several times in the past that there is no way for
a client to authenticate a server over Unix-domain sockets. So
depending on circumstances, a local user could easily insert his own
server and collect passwords and data. Suggestions for possible
remedies included:You can put the socket file in a sufficiently write-protected directory.
But that would strongly deviate from the default setup, and anyway the
client still cannot readily verify that the server is the right one.You can also run SSL over Unix-domain sockets. This is currently
disabled in the code, but it would work just fine. But it's obviously
kind of awkward, and the connection overhead was noticeable in tests.Then it was suggested to use the local "ident" mechanism in reverse, so
the client could verify what user the server runs under. I have
implemented a prototype of this. You can put, e.g.,requirepeer=postgres
into the connection parameters, and the connection will be rejected
unless the process at the other end of the socket is running as
postgres.The patch needs some portability work and possible refactoring because
of that, but before I embark on that, comments on the concept?
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
On tis, 2010-06-22 at 09:37 +0900, KaiGai Kohei wrote:
As you described at the source code comments as follows,
it is not portable except for Linux due to the getsockopt() API.+ // TODO: currently Linux-only code, needs to be made + // portable; see backend/libpq/auth.cI expect it shall be fixed (using the code come from ident_unix()?)
before committing.
Updated patch attached.
Note that the code that gets the user ID from the other end of a socket
appears to have two different modes of operation. On some platforms
(Linux, OpenBSD, Solaris), you call a function and get the answer. On
some other platforms (other BSDs?), you need to send a packet and read
the answer. I don't have any possibility to test the latter approach,
and it seemed a bit complicated to code "blindly". So I have omitted
support for that, but if someone else wants to do the porting, that is
of course possible.
I'd like to point out one other point.
It uses getpwuid() to translate a user identifier into a user name,
but it returns a pointer of the static variable within glibc.
So, it is not thread-safe. I recommend to use getpwnam_r() instead.
Good catch. pqGetpwuid() was actually the right function to use.
Attachments:
serverauth-requirepeer.patchtext/x-patch; charset=UTF-8; name=serverauth-requirepeer.patchDownload
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 8f0a9cf..6a811c5 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -503,6 +503,28 @@
</listitem>
</varlistentry>
+ <varlistentry id="libpq-connect-requirepeer" xreflabel="requirepeer">
+ <term><literal>requirepeer</literal></term>
+ <listitem>
+ <para>
+ For Unix-domain socket connections, if this parameter is
+ set, the client checks at the beginning of the connection
+ that the server process runs under the specified user name,
+ otherwise the connection is aborted with an error. This
+ parameter can be used to achieve the kind of server
+ authentication that SSL certificates achieve on TCP/IP
+ connections. (Note that if the Unix-domain socket is
+ in <filename>/tmp</filename> or another publically writable
+ location, any user could start a server there. Use this
+ parameter to ensure that you are connected to a server run
+ by a trusted user,
+ e.g., <literal>requirepeer=postgres</literal>.) This
+ option is only supported on some platforms, currently
+ Linux, FreeBSD, NetBSD, OpenBSD, BSD/OS, and Solaris.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="libpq-connect-krbsrvname" xreflabel="krbsrvname">
<term><literal>krbsrvname</literal></term>
<listitem>
@@ -6136,6 +6158,16 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
<listitem>
<para>
<indexterm>
+ <primary><envar>PGREQUIREPEER</envar></primary>
+ </indexterm>
+ <envar>PGREQUIREPEER</envar> behaves the same as the <xref
+ linkend="libpq-connect-requirepeer"> connection parameter.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <indexterm>
<primary><envar>PGKRBSRVNAME</envar></primary>
</indexterm>
<envar>PGKRBSRVNAME</envar> behaves the same as the <xref
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index ed37bbd..74595e0 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -226,6 +226,9 @@ static const PQconninfoOption PQconninfoOptions[] = {
{"sslcrl", "PGSSLCRL", NULL, NULL,
"SSL-Revocation-List", "", 64},
+ {"requirepeer", "PGREQUIREPEER", NULL, NULL,
+ "Require-Peer", "", 10},
+
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
/* Kerberos and GSSAPI authentication support specifying the service name */
{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
@@ -592,6 +595,8 @@ fillPGconn(PGconn *conn, PQconninfoOption *connOptions)
conn->sslmode = strdup("require");
}
#endif
+ tmp = conninfo_getval(connOptions, "requirepeer");
+ conn->requirepeer = tmp ? strdup(tmp) : NULL;
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
tmp = conninfo_getval(connOptions, "krbsrvname");
conn->krbsrvname = tmp ? strdup(tmp) : NULL;
@@ -1673,6 +1678,85 @@ keep_going: /* We will come back to here until there is
char *startpacket;
int packetlen;
+#ifdef HAVE_UNIX_SOCKETS
+ if (conn->requirepeer)
+ {
+ char pwdbuf[BUFSIZ];
+ struct passwd pass_buf;
+ struct passwd *pass;
+ uid_t uid;
+
+#if defined(HAVE_GETPEEREID)
+ gid_t gid;
+
+ errno = 0;
+ if (getpeereid(sock, &uid, &gid) != 0)
+ {
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("could not get peer credentials: %s\n"),
+ pqStrerror(errno, sebuf, sizeof(sebuf)));
+ goto error_return;
+ }
+#elif defined(SO_PEERCRED)
+ struct ucred peercred;
+ ACCEPT_TYPE_ARG3 so_len = sizeof(peercred);
+
+ errno = 0;
+ if (getsockopt(conn->sock, SOL_SOCKET, SO_PEERCRED, &peercred, &so_len) != 0 ||
+ so_len != sizeof(peercred))
+ {
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("could not get peer credentials: %s\n"),
+ pqStrerror(errno, sebuf, sizeof(sebuf)));
+ goto error_return;
+ }
+ uid = peercred.uid;
+#elif defined(HAVE_GETPEERUCRED)
+ ucred_t *ucred;
+
+ ucred = NULL; /* must be initialized to NULL */
+ if (getpeerucred(sock, &ucred) == -1)
+ {
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("could not get peer credentials: %s\n"),
+ pqStrerror(errno, sebuf, sizeof(sebuf)));
+ goto error_return;
+ }
+
+ if ((uid = ucred_geteuid(ucred)) == -1)
+ {
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("could not get effective UID from peer credentials: %s\n"),
+ pqStrerror(errno, sebuf, sizeof(sebuf)));
+ goto error_return;
+ }
+ ucred_free(ucred);
+#else
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("requirepeer parameter is not supported on this platform\n"));
+ goto error_return;
+#endif
+
+ pqGetpwuid(uid, &pass_buf, pwdbuf, sizeof(pwdbuf), &pass);
+
+ if (pass == NULL)
+ {
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("local user with ID %d does not exist\n"),
+ (int) peercred.uid);
+ goto error_return;
+ }
+
+ if (strcmp(pass->pw_name, conn->requirepeer) != 0)
+ {
+ appendPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("requirepeer failed (actual: %s != required: %s)\n"),
+ pass->pw_name, conn->requirepeer);
+ goto error_return;
+ }
+ }
+#endif /* HAVE_UNIX_SOCKETS */
+
#ifdef USE_SSL
/*
@@ -2480,6 +2564,8 @@ freePGconn(PGconn *conn)
free(conn->sslrootcert);
if (conn->sslcrl)
free(conn->sslcrl);
+ if (conn->requirepeer)
+ free(conn->requirepeer);
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
if (conn->krbsrvname)
free(conn->krbsrvname);
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index 23d58ff..5fbe24b 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -309,6 +309,7 @@ struct pg_conn
char *sslcert; /* client certificate filename */
char *sslrootcert; /* root certificate filename */
char *sslcrl; /* certificate revocation list filename */
+ char *requirepeer; /* required peer credentials for local sockets */
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
char *krbsrvname; /* Kerberos service name */
(2010/07/01 11:30), Peter Eisentraut wrote:
On tis, 2010-06-22 at 09:37 +0900, KaiGai Kohei wrote:
As you described at the source code comments as follows,
it is not portable except for Linux due to the getsockopt() API.+ // TODO: currently Linux-only code, needs to be made + // portable; see backend/libpq/auth.cI expect it shall be fixed (using the code come from ident_unix()?)
before committing.Updated patch attached.
Note that the code that gets the user ID from the other end of a socket
appears to have two different modes of operation. On some platforms
(Linux, OpenBSD, Solaris), you call a function and get the answer. On
some other platforms (other BSDs?), you need to send a packet and read
the answer. I don't have any possibility to test the latter approach,
and it seemed a bit complicated to code "blindly". So I have omitted
support for that, but if someone else wants to do the porting, that is
of course possible.
I checked the revised patch.
The part to obtain user id of the peer is identical with ident_unix()
on the backend, so I believe it will work well, although I don't have
test environment except for Linux.
I'd like to point out one other point.
It uses getpwuid() to translate a user identifier into a user name,
but it returns a pointer of the static variable within glibc.
So, it is not thread-safe. I recommend to use getpwnam_r() instead.Good catch. pqGetpwuid() was actually the right function to use.
I have a question.
The pqGetpwuid() is enclosed by #ifndef WIN32 ... #endif, although
this patch encloses the section to obtain user id of the peer by
#ifdef HAVE_UNIX_SOCKETS ... #endif.
Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.
I'd like someone to try to build with this patch on win32 platform,
and report it.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
On Fri, Jul 2, 2010 at 8:35 AM, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
(2010/07/01 11:30), Peter Eisentraut wrote:
I have a question.The pqGetpwuid() is enclosed by #ifndef WIN32 ... #endif, although
this patch encloses the section to obtain user id of the peer by
#ifdef HAVE_UNIX_SOCKETS ... #endif.Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.
Win32 never has HAVE_UNIX_SOCKET.
Cygwin might though, I recall some old discussion about that - can't
remember the outcome though, and I can't find it right now.
I'd like someone to try to build with this patch on win32 platform,
and report it.
I think cygwin may be the more important one here.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On fre, 2010-07-02 at 09:16 +0100, Magnus Hagander wrote:
On Fri, Jul 2, 2010 at 8:35 AM, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
(2010/07/01 11:30), Peter Eisentraut wrote:
I have a question.The pqGetpwuid() is enclosed by #ifndef WIN32 ... #endif, although
this patch encloses the section to obtain user id of the peer by
#ifdef HAVE_UNIX_SOCKETS ... #endif.Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.Win32 never has HAVE_UNIX_SOCKET.
Cygwin might though, I recall some old discussion about that - can't
remember the outcome though, and I can't find it right now.
Cygwin doesn't define WIN32 anyway.
Peter Eisentraut wrote:
Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.Win32 never has HAVE_UNIX_SOCKET.
Cygwin might though, I recall some old discussion about that - can't
remember the outcome though, and I can't find it right now.Cygwin doesn't define WIN32 anyway.
Indeed, and we've been very careful to keep it that way.
cheers
andrew
(2010/07/03 1:39), Andrew Dunstan wrote:
Peter Eisentraut wrote:
Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.Win32 never has HAVE_UNIX_SOCKET.
Cygwin might though, I recall some old discussion about that - can't
remember the outcome though, and I can't find it right now.Cygwin doesn't define WIN32 anyway.
Indeed, and we've been very careful to keep it that way.
Sorry for the late responding.
I marked this patch 'ready for committer'.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>