From: | Robbie Harwood <rharwood(at)redhat(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: [PATCH v12] GSSAPI encryption support |
Date: | 2016-07-26 15:22:24 |
Message-ID: | jlg7fc8fmq7.fsf@thriss.redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
>> Robbie Harwood <rharwood(at)redhat(dot)com> writes:
>
> Sorry for my late reply.
Thanks for the feedback!
>>> If I were to continue as I have been - using the plaintext connection
>>> and auth negotiation path - then at the time of startup the client has
>>> no way of knowing whether to send connection parameters or not.
>>> Personally, I would be in favor of not frontloading these connection
>>> parameters over insecure connections, but it is my impression that the
>>> project does not want to go this way (which is fine).
>
> Per the discussion upthread I got the opposite impression, the startup
> packet should be sent after the connection has been established. SSL
> does so: the SSL negotiation goes first, and then the startup packet
> is sent. That's the flow with the status changing from
> CONNECTION_SSL_START -> CONNECTION_MADE.
We are in agreement, I think. I have structured the referenced
paragraph badly: for this design, I'm suggesting separate GSS startup
path (like SSL) and once a tunnel is established we send the startup
packet. I probably should have just left this paragraph out.
>>> On the server, I'll need to implement `hostgss` (by analogy to
>>> `hostssl`), and we'll want to lock authentication on those connections
>>> to GSSAPI-only.
>
> As well as hostnogss, but I guess that's part of the plan.
Sure, `hostnogss` should be fine. This isn't quadratic, right? We don't
need hostnogssnossl (or thereabouts)?
>>> Clients will explicitly probe for GSSAPI support as they do for TLS
>>> support (I look forward to the bikeshed on the order of these) and
>>> should have a parameter to require said support. One thing I'm not
>>> clear on is what our behavior should be when the user doesn't
>>> explicitly request GSSAPI and doesn't have a ccache - do we prompt?
>>> Skip probing? I'm not sure what the best option there is.
>
> I am not sure I get what you mean here.
Okay. Let me try again:
So there's a connection setting `sslmode` that we'll want something
similar to here (`gssapimode` or so). `sslmode` has six settings, but I
think we only need three for GSSAPI: "disable", "allow", and "prefer"
(which presumably would be the default).
Lets suppose we're working with "prefer". GSSAPI will itself check two
places for credentials: client keytab and ccache. But if we don't find
credentials there, we as the client have two options on how to proceed.
- First, we could prompt for a password (and then call
gss_acquire_cred_with_password() to get credentials), presumably with
an empty password meaning to skip GSSAPI. My memory is that the
current behavior for GSSAPI auth-only is to prompt for password if we
don't find credentials (and if it isn't, there's no reason not to
unless we're opposed to handling the password).
- Second, we could skip GSSAPI and proceed with the next connection
method. This might be confusing if the user is then prompted for a
password and expects it to be for GSSAPI, but we could probably make
it sensible. I think I prefer the first option.
Thanks,
--Robbie
From | Date | Subject | |
---|---|---|---|
Next Message | Robbie Harwood | 2016-07-26 15:28:11 | Re: [PATCH v12] GSSAPI encryption support |
Previous Message | Tom Lane | 2016-07-26 15:10:14 | Re: Proposal: revert behavior of IS NULL on row types |