Re: Support kerberos authentication for postgres_fdw

From: Peifeng Qiu <peifengq(at)vmware(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support kerberos authentication for postgres_fdw
Date: 2021-07-14 09:30:18
Message-ID: CO1PR05MB80232268E7759567BD7024FFA8139@CO1PR05MB8023.namprd05.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all.

I've come up with a proof-of-concept patch using the delegation/proxy approach.

Let's say we have two DB, one for FDW and one for the real server. When client
connects to FDW server using kerberos authentication, we can obtain a "proxy"
credential and store it in the global variable "MyProcPort->gss->proxy". This can
be then passed to gssapi calls during libpq kerberos setup when the foreign table
is queried.

This will mitigate the need for keytab file on FDW server. We will also have to
relax the password requirement for user mapping.

The big problem here is how to pass proxy credential from backend to libpq-fe
safely. Because libpq called in postgres_fdw is compiled as frontend binary, we'd
better not include any backend related stuff in libpq-fe.
In this patch I use a very ugly hack to work around this. First take pointer address
of the variable MyProcPort->gss->proxy, convert it to hex string, and then pass
it as libpq option "gss_proxy_cred". Any idea about how to do this in a more
elegant way?

Best regards,
Peifeng

Attachment Content-Type Size
v2-0001-kerberos-pgfdw.patch text/x-patch 8.5 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-07-14 09:38:15 Re: row filtering for logical replication
Previous Message Amit Kapila 2021-07-14 09:29:26 Re: row filtering for logical replication