Patch: use SCM_CREDS authentication over PF_LOCAL sockets
The following set of patches (relative to 7.1.2 release) implement
SCM_CREDS authentication for local connections. On systems which
support it, this mechanism should be used instead of `trust' for local
connections.
-GAWollman
------------------------------------------------------------------------
--- src/backend/libpq/auth.c Wed Mar 21 22:59:30 2001
+++ src/backend/libpq/auth.c Sun Aug 12 14:46:35 2001
@@ -26,6 +26,11 @@
#include <ctype.h> #include <sys/types.h> /* needed by in.h on Ultrix */
+#include <sys/socket.h> /* for SCM_CREDS */
+#ifdef SCM_CREDS
+#include <sys/uio.h> /* for struct iovec */
+#include <errno.h>
+#endif
#include <netinet/in.h>
#include <arpa/inet.h>@@ -42,6 +47,7 @@
static int handle_done_auth(void *arg, PacketLen len, void *pkt);
static int handle_krb4_auth(void *arg, PacketLen len, void *pkt);
static int handle_krb5_auth(void *arg, PacketLen len, void *pkt);
+static int handle_local_auth(void *arg, PacketLen len, void *pkt);
static int handle_password_auth(void *arg, PacketLen len, void *pkt);
static int readPasswordPacket(void *arg, PacketLen len, void *pkt);
static int pg_passwordv0_recvauth(void *arg, PacketLen len, void *pkt);
@@ -322,6 +328,98 @@
#endif /* KRB5 */+#ifdef SCM_CREDS
+static int
+pg_local_recvauth(Port *port)
+{
+ struct msghdr msg;
+ struct {
+ struct cmsghdr hdr;
+ struct cmsgcred cred;
+ } cmsg;
+ struct iovec iov;
+ char buf;
+ char namebuf[SM_USER + 1];
+ struct passwd *pw;
+
+ msg.msg_name = NULL;
+ msg.msg_namelen = 0;
+ msg.msg_iov = &iov;
+ msg.msg_iovlen = 1;
+ msg.msg_control = (char *)&cmsg;
+ msg.msg_controllen = sizeof cmsg;
+ msg.msg_flags = 0;
+
+ /*
+ * The one character which is received here is not meaningful;
+ * its purposes is only to make sure that recvmsg() blocks
+ * long enough for the other side to send its credentials.
+ */
+ iov.iov_base = &buf;
+ iov.iov_len = 1;
+
+ if (recvmsg(port->sock, &msg, 0) < 0) {
+ snprintf(PQerrormsg, PQERRORMSG_LENGTH,
+ "pg_local_recvauth: error receiving credentials: %s\n",
+ strerror(errno));
+errout:
+ fputs(PQerrormsg, stderr);
+ pqdebug("%s", PQerrormsg);
+
+ return STATUS_ERROR;
+ }
+
+ /*
+ * Make sure we got the right kind of message.
+ */
+ if (cmsg.hdr.cmsg_len != sizeof cmsg
+ || cmsg.hdr.cmsg_level != SOL_SOCKET
+ || cmsg.hdr.cmsg_type != SCM_CREDS) {
+ snprintf(PQerrormsg, PQERRORMSG_LENGTH,
+ "pg_local_recvauth: protocol error receiving credentials\n");
+ goto errout;
+ }
+
+ snprintf(PQerrormsg, PQERRORMSG_LENGTH,
+ "pg_local_recvauth: pid %lu, uid %lu\n",
+ (unsigned long)cmsg.cred.cmcred_pid,
+ (unsigned long)cmsg.cred.cmcred_uid);
+ pqdebug("%s", PQerrormsg);
+
+ strncpy(namebuf, port->user, SM_USER);
+ namebuf[SM_USER] = '\0';
+
+ pw = getpwnam(namebuf);
+ if (pw == NULL) {
+ snprintf(PQerrormsg, PQERRORMSG_LENGTH,
+ "pg_local_recvauth: unknown local user %s\n",
+ namebuf);
+ goto errout;
+ }
+
+ if (pw->pw_uid != cmsg.cred.cmcred_uid) {
+ snprintf(PQerrormsg, PQERRORMSG_LENGTH,
+ "pg_local_recvauth: %s's uid %lu != real uid %lu\n",
+ namebuf, (unsigned long)pw->pw_uid,
+ (unsigned long)cmsg.cred.cmcred_uid);
+ goto errout;
+ }
+ return STATUS_OK;
+}
+
+#else
+static int
+pg_local_recvauth(Port *port)
+{
+ snprintf(PQerrormsg, PQERRORMSG_LENGTH,
+ "pg_local_recvauth: credential passing not implemented on this server.\n");
+ fputs(PQerrormsg, stderr);
+ pqdebug("%s", PQerrormsg);
+
+ return STATUS_ERROR;
+}
+#endif /* SCM_CREDS */
+
/*
* Handle a v0 password packet.
*/
@@ -439,6 +537,9 @@
case uaCrypt:
authmethod = "Password";
break;
+ case uaLocalCred:
+ authmethod = "Local credential";
+ break;
} sprintf(buffer, "%s authentication failed for user '%s'",
@@ -545,6 +646,10 @@
areq = AUTH_REQ_CRYPT;
auth_handler = handle_password_auth;
break;
+ case uaLocalCred:
+ areq = AUTH_REQ_LOCALCRED;
+ auth_handler = handle_local_auth;
+ break;
} /* Tell the frontend what we want next. */
@@ -668,6 +773,24 @@
/*
+ * Called when we have told the front end that it should use local
+ * credential authentication.
+ */
+
+static int
+handle_local_auth(void *arg, PacketLen len, void *pkt)
+{
+ Port *port = (Port *) arg;
+
+ if (pg_local_recvauth(port) != STATUS_OK)
+ auth_failed(port);
+ else
+ sendAuthRequest(port, AUTH_REQ_OK, handle_done_auth);
+
+ return STATUS_OK;
+}
+
+/*
* Called when we have received the password packet.
*/@@ -777,6 +900,10 @@
case uaTrust:
status = STATUS_OK;
+ break;
+
+ case uaLocalCred: /* can't happen */
+ status = STATUS_ERROR;
break; case uaIdent:
--- src/backend/libpq/hba.c Fri Feb 9 21:31:26 2001
+++ src/backend/libpq/hba.c Sun Aug 12 14:10:28 2001
@@ -125,6 +125,8 @@
*userauth_p = uaReject;
else if (strcmp(buf, "crypt") == 0)
*userauth_p = uaCrypt;
+ else if (strcmp(buf, "local") == 0)
+ *userauth_p = uaLocalCred;
else
{
*error_p = true;
@@ -279,6 +281,14 @@
*/ read_hba_entry2(file, &port->auth_method, port->auth_arg, error_p);
+
+ /*
+ * Disallow authentication methods which require a PF_LOCAL
+ * socket.
+ */
+ if (!*error_p &&
+ (port->auth_method == uaLocalCred))
+ *error_p = true; if (*error_p)
goto syntax;
--- src/backend/libpq/pg_hba.conf.sample Tue Nov 21 15:44:32 2000
+++ src/backend/libpq/pg_hba.conf.sample Sun Aug 12 14:17:41 2001
@@ -96,6 +96,12 @@
# trust: No authentication is done. Trust that the user has the
# authority to use whatever username he specifies.
#
+# local: Use the credential-passing feature of local-domain sockets
+# (available only on certain operating systems) to
+# authenticate the user. Allow the user access if his
+# real UID matches the UID in the system password file
+# for the requested username.
+#
# password: Authentication is done by matching a password supplied
# in clear by the host. If AUTH_ARGUMENT is specified then
# the password is compared with the user's entry in that
@@ -123,7 +129,7 @@
#
# reject: Reject the connection.
#
-# Local (UNIX socket) connections support only AUTHTYPEs "trust",
+# Local (UNIX socket) connections support only AUTHTYPEs "trust", "local",
# "password", "crypt", and "reject".@@ -137,9 +143,18 @@
#
# host all 127.0.0.1 255.255.255.255 trust
#
-# The same, over Unix-socket connections:
+# Allow any user to connect to any database over a local socket,
+# provided that the user's real UID is the same as the requested
+# database username's UID:
+#
+# local all local
+#
+# On operating systems where credential passing over local sockets
+# is not available, allow any user to connect to any database over
+# a local socket under any username:
#
# local all trust
+#
#
# Allow any user from any host with IP address 192.168.93.x to
# connect to database "template1" as the same username that ident on that
--- src/include/libpq/hba.h Wed Mar 21 23:00:47 2001
+++ src/include/libpq/hba.h Sun Aug 12 13:33:30 2001
@@ -35,7 +35,8 @@
uaTrust,
uaIdent,
uaPassword,
- uaCrypt
+ uaCrypt,
+ uaLocalCred
} UserAuth; typedef struct Port hbaPort;
--- src/include/libpq/pqcomm.h Wed Mar 21 23:00:48 2001
+++ src/include/libpq/pqcomm.h Sun Aug 12 13:35:16 2001
@@ -90,7 +90,7 @@
/* The earliest and latest frontend/backend protocol version supported. */ #define PG_PROTOCOL_EARLIEST PG_PROTOCOL(0,0)
-#define PG_PROTOCOL_LATEST PG_PROTOCOL(2,0)
+#define PG_PROTOCOL_LATEST PG_PROTOCOL(2,1) /*
* All packets sent to the postmaster start with the length. This is omitted
@@ -132,6 +132,7 @@
#define AUTH_REQ_KRB5 2 /* Kerberos V5 */
#define AUTH_REQ_PASSWORD 3 /* Password */
#define AUTH_REQ_CRYPT 4 /* Encrypted password */
+#define AUTH_REQ_LOCALCRED 5 /* PF_LOCAL credentials */typedef uint32 AuthRequest;
--- src/interfaces/libpq/fe-auth.c Wed Mar 21 23:01:25 2001
+++ src/interfaces/libpq/fe-auth.c Sun Aug 12 14:50:44 2001
@@ -43,6 +43,11 @@
#ifndef MAXHOSTNAMELEN
#include <netdb.h> /* for MAXHOSTNAMELEN on some */
#endif
+#include <sys/socket.h> /* for SCM_CREDS */
+#ifdef SCM_CREDS
+#include <sys/uio.h>
+#include <sys/errno.h>
+#endif
#include <pwd.h>
#endif@@ -430,6 +435,52 @@
#endif /* KRB5 */
+#ifdef SCM_CREDS
+static int
+pg_local_sendauth(char *PQerrormsg, PGconn *conn)
+{
+ char buf;
+ struct iovec iov;
+ struct {
+ struct cmsghdr hdr;
+ struct cmsgcred cred;
+ } cmsg;
+ struct msghdr msg;
+
+ /*
+ * The backend doesn't care what we send here, but it wants
+ * exactly one character to force recvmsg() to block and wait
+ * for us.
+ */
+ buf = '\0';
+ iov.iov_base = &buf;
+ iov.iov_len = 1;
+
+ cmsg.hdr.cmsg_len = sizeof cmsg;
+ cmsg.hdr.cmsg_level = SOL_SOCKET;
+ cmsg.hdr.cmsg_type = SCM_CREDS;
+ /*
+ * cmsg.cred will get filled in with the correct information
+ * by the kernel when this message is sent.
+ */
+
+ msg.msg_name = NULL;
+ msg.msg_namelen = 0;
+ msg.msg_iov = &iov;
+ msg.msg_iovlen = 1;
+ msg.msg_control = &cmsg;
+ msg.msg_controllen = sizeof cmsg;
+ msg.msg_flags = 0;
+
+ if (sendmsg(conn->sock, &msg, 0) == -1) {
+ snprintf(PQerrormsg, PQERRORMSG_LENGTH,
+ "pg_local_sendauth: sendmsg: %s", strerror(errno));
+ return STATUS_ERROR;
+ }
+ return STATUS_OK;
+}
+#endif
+
static int
pg_password_sendauth(PGconn *conn, const char *password, AuthRequest areq)
{
@@ -507,6 +558,17 @@
} break;
+
+ case AUTH_REQ_LOCALCRED:
+#ifdef SCM_CREDS
+ if (pg_local_sendauth(PQerrormsg, conn) != STATUS_OK)
+ return STATUS_ERROR;
+ break;
+#else
+ (void) sprintf(PQerrormsg,
+ "fe_sendauth: local authentication not supported\n");
+ return STATUS_ERROR;
+#endif default:
(void) sprintf(PQerrormsg,
wollman@LCS.MIT.EDU writes:
The following set of patches (relative to 7.1.2 release) implement
SCM_CREDS authentication for local connections.
Unfortunately, there's little chance that this will apply cleanly to
current sources, since we've restructured the postmaster's handling of
the authorization process.
A more significant objection is that you've extended the wire protocol
by adding a new authorization protocol, but have fixed only one client
library and not touched the protocol documentation at all. There's a
lot more work needed to make this a complete patch.
BTW, current sources already contain support for using
getsockopt(SO_PEERCRED) where available --- AFAIK that's only Linux,
but perhaps that's all you need.
regards, tom lane
<<On Mon, 13 Aug 2001 10:14:14 -0400, Tom Lane <tgl@sss.pgh.pa.us> said:
A more significant objection is that you've extended the wire protocol
by adding a new authorization protocol, but have fixed only one client
library and not touched the protocol documentation at all. There's a
lot more work needed to make this a complete patch.
It works for me, in the applications that I care about, and that's all
matters to me. If you don't want to take advantage of the work that
I've done (it took about an hour), that's not my concern.
BTW, current sources already contain support for using
getsockopt(SO_PEERCRED) where available --- AFAIK that's only Linux,
but perhaps that's all you need.
I have no interest in Linux.
-GAWollman
On Mon, 13 Aug 2001, Garrett Wollman wrote:
<<On Mon, 13 Aug 2001 10:14:14 -0400, Tom Lane <tgl@sss.pgh.pa.us> said:
A more significant objection is that you've extended the wire protocol
by adding a new authorization protocol, but have fixed only one client
library and not touched the protocol documentation at all. There's a
lot more work needed to make this a complete patch.It works for me, in the applications that I care about, and that's all
matters to me. If you don't want to take advantage of the work that
I've done (it took about an hour), that's not my concern.
First off, as Tom states, it won't apply to current sources ... can you
supply a patch that will work with -CURRENT?
Second, are you willing to provide patches for the protocol documentation?
Third, and more directed to Tom ... if applied, would this break the other
client libraries, or only make it available to those that have been fixed?
"Marc G. Fournier" <scrappy@hub.org> writes:
Third, and more directed to Tom ... if applied, would this break the other
client libraries, or only make it available to those that have been fixed?
Unextended clients should fail with reasonable grace, AFAIK. I wasn't
objecting to the notion of adding an auth method on those grounds,
merely pointing out that there's more work to be done.
regards, tom lane
Tom Lane writes:
BTW, current sources already contain support for using
getsockopt(SO_PEERCRED) where available --- AFAIK that's only Linux,
but perhaps that's all you need.
Is this feature any different from the fake local ident we've put it?
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
BTW, current sources already contain support for using
getsockopt(SO_PEERCRED) where available --- AFAIK that's only Linux,
but perhaps that's all you need.
Is this feature any different from the fake local ident we've put it?
Yes. Wollman's code uses an SCM_CREDS message, which means (a) it will
work on Solaris and one or two other Unixen, not only Linux; but (b)
it requires client-side code additions, not only server-side code.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
BTW, current sources already contain support for using
getsockopt(SO_PEERCRED) where available --- AFAIK that's only Linux,
but perhaps that's all you need.Is this feature any different from the fake local ident we've put it?
Yes. Wollman's code uses an SCM_CREDS message, which means (a) it will
work on Solaris and one or two other Unixen, not only Linux; but (b)
it requires client-side code additions, not only server-side code.
BSD/OS supports it, and I assume FreeBSD too.
\
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Peter Eisentraut <peter_e@gmx.net> writes:
BTW, current sources already contain support for using
getsockopt(SO_PEERCRED) where available --- AFAIK that's only Linux,
but perhaps that's all you need.Is this feature any different from the fake local ident we've put it?
Yes. Wollman's code uses an SCM_CREDS message, which means (a) it will
work on Solaris and one or two other Unixen, not only Linux; but (b)
it requires client-side code additions, not only server-side code.
My upcoming MD5 patch will conflict with this anyway. Also, I just found
out that ODBC doesn't even do crypt authentication! Anyway, I will
merge this into current sources. Seems we can add it to ODBC and JDBC
later, just like the MD5 changes.
Is that OK with everyone. Since we have peer with Linux, seems we
should add CRED_ in the same release.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026<<On Tue, 14 Aug 2001 20:54:42 -0400 (EDT), Bruce Momjian <pgman@candle.pha.pa.us> said:
Is that OK with everyone. Since we have peer with Linux, seems we
should add CRED_ in the same release.
One thing to be careful about: there are several different versions of
this functionality, and not all of them use the same data structures.
Probably you should include a configure test to figure out which
version is available.
-GAWollman
<<On Tue, 14 Aug 2001 20:54:42 -0400 (EDT), Bruce Momjian <pgman@candle.pha.pa.us> said:
Is that OK with everyone. Since we have peer with Linux, seems we
should add CRED_ in the same release.One thing to be careful about: there are several different versions of
this functionality, and not all of them use the same data structures.
Probably you should include a configure test to figure out which
version is available.
That is some information I really need. I only have BSD/OS here. I can
apply the patch and let you test it on your end, or if you can send over
some info, we can get it into configure.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026The following set of patches (relative to 7.1.2 release) implement
SCM_CREDS authentication for local connections. On systems which
support it, this mechanism should be used instead of `trust' for local
connections.
OK, here is a cleaned up version of the patch that will apply to current
CVS. I worked it into the SO_PEERCRED code. I made some changes so it
compiles on BSD/OS. I am getting "Invalid Argument" from libpq's
sending of the credentials on BSD/OS. I would be interested to know if
this works on FreeBSD. Solaris uses this capability too.
Also, we are not updating the protocol version, so I hope it fails
gracefully on old clients.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Attachments:
/pgpatches/scmtext/plainDownload+207-118
<<On Thu, 16 Aug 2001 00:34:14 -0400 (EDT), Bruce Momjian <pgman@candle.pha.pa.us> said:
OK, here is a cleaned up version of the patch that will apply to current
CVS. I worked it into the SO_PEERCRED code. I made some changes so it
compiles on BSD/OS. I am getting "Invalid Argument" from libpq's
sending of the credentials on BSD/OS.There are some funky alignment macros that you probably need to use on
BSD/OS. Also, as written this will break on NetBSD and OpenBSD for
reasons I have already noted (the structure is named something
different there), and those systems will also require the alignment
macros. (Basically, putting the two structures in another larger
structure is a shortcut in my implementation which only works because
the compiler puts the right amount of padding in; on those other
systems, more padding is required.)
I got some more information this morning. First, BSD/OS doesn't like to
have the credentials record attached to the message. I was getting
"Invalid argument" when I did that. It just wants the packet. Second,
BSD/OS has a LOCAL_CREDS call to pass the credentials. I am working on
another patch but will get back to this shortly.
"To get credentials sent (once on a stream socket, every time on
a datagram socket) you just want to do a setsockopt() to set
the LOCAL_CREDS option:
int on = 1;
error = setsockopt(s, 0, LOCAL_CREDS, &on, sizeof on);
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Import Notes
Reply to msg id not found: 200108161720.f7GHKrX55122@khavrinen.lcs.mit.edu | Resolved by subject fallback
<<On Thu, 16 Aug 2001 00:34:14 -0400 (EDT), Bruce Momjian <pgman@candle.pha.pa.us> said:
OK, here is a cleaned up version of the patch that will apply to current
CVS. I worked it into the SO_PEERCRED code. I made some changes so it
compiles on BSD/OS. I am getting "Invalid Argument" from libpq's
sending of the credentials on BSD/OS.There are some funky alignment macros that you probably need to use on
BSD/OS. Also, as written this will break on NetBSD and OpenBSD for
reasons I have already noted (the structure is named something
different there), and those systems will also require the alignment
macros. (Basically, putting the two structures in another larger
structure is a shortcut in my implementation which only works because
the compiler puts the right amount of padding in; on those other
systems, more padding is required.)
OK, attached is my current version of the patch. Would you download the
snapshot or CVS and let me know if this works on FreeBSD. Even if you
can't run it, can you tell me if it compiles.
Also, attached is the BSD/OS manual page that shows the use of the
macros for retrieving SCM. Can you add that and send me an updated
patch? Also, can you check to see if FreeBSD requires you to send the
full struct with empty cred, or if you can just send the header without
the struct. You will see in my patch for the libpq client part that
BSD/OS doesn't want the extra struct.
Looks like 7.2 is going to have overhauled authentication, and I would
really like to get this SCM stuff nailed down on as many platforms as
possible before going beta, which may happen as early as September 1.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Import Notes
Reply to msg id not found: 200108161720.f7GHKrX55122@khavrinen.lcs.mit.edu | Resolved by subject fallback
There are some funky alignment macros that you probably need to use on
BSD/OS. Also, as written this will break on NetBSD and OpenBSD for
reasons I have already noted (the structure is named something
different there), and those systems will also require the alignment
macros. (Basically, putting the two structures in another larger
structure is a shortcut in my implementation which only works because
the compiler puts the right amount of padding in; on those other
systems, more padding is required.)
OK, here is an even better version. It handles the lack of alignment in
the the structure passing. This works on BSD/OS and should work on
FreeBSD too.
I will apply it in a day or so unless someone finds a problem.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Attachments:
/pgpatches/scmtext/plainDownload+198-102
Import Notes
Reply to msg id not found: 200108161720.f7GHKrX55122@khavrinen.lcs.mit.edu | Resolved by subject fallback
Bruce Momjian writes:
OK, here is an even better version. It handles the lack of alignment in
the the structure passing. This works on BSD/OS and should work on
FreeBSD too.
Since this patch overwrites the previous SO_PEERCRED patch I assume you
want it to work on Linux, too. On Linux SCM_CREDS is called
SCM_CREDENTIALS. There's no sys/ucred.h (use sys/socket.h instead), and
there's no fc_uid, though I don't know what that does. The invocation
changes to StrNCpy look suspicious; see the comment at StrNCpy in c.h. In
one place you include errno.h twice.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
Since this patch overwrites the previous SO_PEERCRED patch I assume you
want it to work on Linux, too. On Linux SCM_CREDS is called
SCM_CREDENTIALS.
Overwrite? It looks like an addition to me. I think the #ifdef tests
in ident_unix are in the wrong order, however: we should prefer
SO_PEERCRED if available, since that works with old clients. As written
the postmaster code will select SCM_CREDS if both methods are available,
which is the wrong choice IMHO.
The invocation
changes to StrNCpy look suspicious; see the comment at StrNCpy in c.h. In
one place you include errno.h twice.
These are good points.
regards, tom lane
Bruce Momjian writes:
OK, here is an even better version. It handles the lack of alignment in
the the structure passing. This works on BSD/OS and should work on
FreeBSD too.Since this patch overwrites the previous SO_PEERCRED patch I assume you
want it to work on Linux, too. On Linux SCM_CREDS is called
Actually, I made the test for CRED's before PEER because I thought
CRED's was more portable, and because there is a test where I ask for a
dummy send so I can get the creds and if I did PEER first, I would have
to do an #ifdef PEER then #ifdef SCM which seemed kind of weird. I did
document that I was defining CRED first. I can easily prefer PEER if
people think that is better.
SCM_CREDENTIALS. There's no sys/ucred.h (use sys/socket.h instead), and
Interesting. Should we remove PEER and go with some kind of CRED's on
all platforms? Remember, PEER hasn't been released yet in our code. It
came from Debian and was only used there in a beta release.
there's no fc_uid, though I don't know what that does. The invocation
changes to StrNCpy look suspicious; see the comment at StrNCpy in c.h. In
one place you include errno.h twice.
I see:
char ident_user[IDENT_USERNAME_MAX + 1];
with StrNCpy as:
StrNCpy(ident_user, pw->pw_name, IDENT_USERNAME_MAX+1);
Am I missing something?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Peter Eisentraut <peter_e@gmx.net> writes:
Since this patch overwrites the previous SO_PEERCRED patch I assume you
want it to work on Linux, too. On Linux SCM_CREDS is called
SCM_CREDENTIALS.Overwrite? It looks like an addition to me. I think the #ifdef tests
in ident_unix are in the wrong order, however: we should prefer
SO_PEERCRED if available, since that works with old clients. As written
the postmaster code will select SCM_CREDS if both methods are available,
which is the wrong choice IMHO.
Yes, but I mentioned PEERCRED is new in 7.2 and wasn't widely
distributed by Debian, so we should decide which we want first. Also,
let me mention that this could turn out to be a portability headache.
We currently support two SCM_CRED implementations, FreeBSD and BSD/OS,
and they are both different. I found:
Linux : SO_PEERCRED
FreeBSD: SCM_CREDS
BSD/OS: SCM_CREDS (different from FreeBSD)
NetBSD: LOCAL_CREDS
Solaris: Doors
from a 1999 message:
http://cert.uni-stuttgart.de/archive/bugtraq/1999/01/msg00098.html
I also found this mention:
BSD/OS, FreeBSD and other BSD derived operating systems also
have SCM_CREDS that sends credential information through a UNIX
domain socket. [ Ok, someone point me to some standard that
documents the semantics. Every BSD camp is doing it differently
":( ]
in a 1999 FAQ:
http://www.attrition.org/~modify/texts/unix/secure-faq.txt
I am slightly concerned that a platform will define SCM_CREDS but not
have an interface we support. However, from the list above, it seems we
may be safe but not support NetBSD or Solaris versions.
FYI, this email states why BSD/OS and FreeBSD are different. The
implementor didn't know of the BSD/OS implementation:
I think this is a valuable feature to reduce the need to configure local
users as 'trust' or use 'ident' on local tcp/ip sockets. One possible
solution would be to enable SCM_CREDS _only_ on BSD/OS and FreeBSD and
wait for others to verify it works on their platforms or submit a patch.
The invocation
changes to StrNCpy look suspicious; see the comment at StrNCpy in c.h. In
one place you include errno.h twice.These are good points.
Removed the duplicate errno. Thanks. I checked the StrNCpy call and I
can't see the problem. I wrote the thing. Have I been away from this
too long? :-)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
Yes, but I mentioned PEERCRED is new in 7.2 and wasn't widely
distributed by Debian, so we should decide which we want first. Also,
let me mention that this could turn out to be a portability headache.
Based on your other message, SCM_CREDS will be much more of a
portability headache than PEERCRED. All the more reason to prefer
the latter if available.
regards, tom lane