On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood <rharw...@redhat.com> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: > >> On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood <rharw...@redhat.com> wrote: >>> Robbie Harwood <rharw...@redhat.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.
OK we're good then. >>>> 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)? We don't need to do that far, users could still do the same with two different lines in pg_hba.conf. > 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). Seeing the debate regarding sslmode these days, I would not say that "prefer" would be the default, but that's an implementation detail. > 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. Ah, right. I completely forgot that GSSAPI had its own handling of passwords for users registered to it... Isn't this distinction a good point for not implementing "prefer", "allow" or any equivalents? By that I mean that we should not have any GSS connection mode that fallbacks to something else if the first one fails. So we would live with the two following modes: - "disable", to only try a non-GSS connection - "enable", or "require", to only try a GSS connection. That seems quite acceptable to me as a first implementation to just have that. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
