Re: [PATCH v2] GSSAPI encryption support - Mailing list pgsql-hackers
From | Robbie Harwood |
---|---|
Subject | Re: [PATCH v2] GSSAPI encryption support |
Date | |
Msg-id | jlgvbba5fu4.fsf@thriss.redhat.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
|
List | pgsql-hackers |
Michael Paquier <michael.paquier@gmail.com> writes: > 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. I'm sorry to hear that FreeIPA didn't work for you. I'd be remiss if I didn't suggest you file bugs against the project for things that are broken, though that's somewhat orthogonal to the patchset at hand. I gave your setup a try; I spun up a fc22 machine (krb5v1.13.2), and installed the KDC as per your instructions. I only did two things differently: I'm using the default unit file for krb5kdc, and I'm using the postgres base dir /var/lib/pgsql/data (this is a Fedora default and I'm sure it doesn't matter for purposes of this). I have no issues, no sync loss; nothing is amiss as far as I can see. If there is actually a problem here, I need more information from you. At the very least, as previously mentioned, I need to know what messages went over the wire to/from the server before it occurred, and what command (if it it made it to command processing) it was in the midst of sending. Thanks, --Robbie
pgsql-hackers by date: