Re: [PATCH v2] GSSAPI encryption support - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH v2] GSSAPI encryption support
Date
Msg-id CAB7nPqTgr+aOZFmbORwxX9sZ7f3re4FuQFZyqdHP8AnOZPqrgw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH v2] GSSAPI encryption support  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [PATCH v2] GSSAPI encryption support  (Robbie Harwood <rharwood@redhat.com>)
List pgsql-hackers
On Thu, Sep 10, 2015 at 4:27 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Sep 10, 2015 at 1:44 AM, Robbie Harwood <rharwood@redhat.com> wrote:
>> Michael Paquier <michael.paquier@gmail.com> writes:
>>
>>> On Wed, Sep 9, 2015 at 4:12 AM, Robbie Harwood wrote:
>>>> Michael Paquier writes:
>>>> As promised, here's a V2 to address your issues with comments.  I
>>>> haven't heard back on the issues you found in testing, so no other
>>>> changes are present.
>>>
>>> Well, the issue is still here: login through gssapi fails with your
>>> patch, not with HEAD. This patch is next on my review list by the way
>>> so I'll see what I can do about it soon even if I am in the US for
>>> Postgres Open next week. Still, how did you test it? I am just
>>> creating by myself a KDC, setting up a valid credential with kinit,
>>> and after setting up Postgres for this purpose the protocol
>>> communication just fails.
>>
>> My KDC is setup through freeIPA; I create a service for postgres,
>> acquire a keytab, set it in the config file, and fire up the server.  It
>> should go without saying that this is working for me, which is why I
>> asked you for more information so I could try to debug.  I wrote a post
>> on this back in June when this was still in development:
>> http://mivehind.net/page/view-page-slug/16/postgres-kerberos
> Hm. OK. I'll give it a try with freeipa and your patch with Fedora for
> example. Could you as well try the configuration I have used? In any
> case, it seems to me that we have a real problem with your patch: the
> gss authentication protocol is broken with your patch and *not* HEAD
> when using a custom kdc like the one I have set up manually on one of
> my VMs.

Looking more at this stuff. Your post assumes that you have an IPA
server available (I am not really familiar with this software stack)
already configured at hand so as you do not need to worry about any
low-level configuration and a KDC is provided as well, among other
things like ntpd or an apache instance. Well, the thing is that we
just need is a KDC for this patch to have an environment suitable for
testing, and some magic commands with kadmin.local, kinit, etc, and
not the whole set of features that an IPA server provides (when
kicking ipa-server-install one needs to provide a realm name, a KDC
admin password, so that's basically just a wrapper setting up
krb5.conf, which is handy when you want to have the full set in your
hands actually, though just to test this patch it does not seem worth
it). And I imagine that you do have an IPA server already set
facilitating your work.

Still, I gave it a try on a Fedora host, giving up after facing
several failures when trying to install the server. because of several
features.

Note that by duckduckging around I have bumped into some more
documentation to set up KDC with Postgres:
http://gpdb.docs.pivotal.io/4320/admin_guide/kerberos.html
This may be useful when testing this patch as well.
Regards,
-- 
Michael



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: RLS open items are vague and unactionable
Next
From: Fabien COELHO
Date:
Subject: Re: Partitioned checkpointing