On Jul 31, 2008, at 7:58 AM, Magnus Hagander wrote:
Stephen Frost wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I'm making no promises, but what would people think of a hostgss hba
option?
As described, sounds like a win to me. It'd be very nice to be
able to
just use GSSAPI encryption on the link. That, combined w/ Magnus'
work
on username/princ mappings, would really bring PostgreSQL up to
date wrt
GSSAPI support.
Yeah, +1 on this feature, it would be quite useful.
It'd really be great to have this support in the ODBC and JDBC
drivers
too.. I think in JDBC it might 'just work', I'm less sure about
ODBC.
ODBC will need hackery I think. They use libpq for authentication
only,
but have their own SSL code and such. I do think ODBC would be a
fairly
major point to it being a success, though, so it'd be good if a plan
could be secured for it. But it's not a showstopper, of course.
I don't know enough about ODBC. If ODBC does SSL independently of PG
then it requires thought by someone who understands ODBC.
As a practical question- would you really need a seperate explicit
pg_hba option for it? It'd be nice to be able to require it, if
desired, but that strikes me as more sensible as an option to the
'gss'
auth mechanism?
Yeah, if we can get rid of that, that'd be good. The stuff I'm working
on will allow us to have multiple parameters for each row in name/
value
pairs, so if we could use that, it'd be better. (I've been considering
changing how host/hostssl work that way as well - by having a
parameter
similar to what we have on the client side with sslmode=...)
A thought that I came across - is it even possible to use GSSAPI
encryption *without* using GSSAPI authentication? If not, it really
seems like it should belong more in the parameter part of the field.
Since in that case it is also not possible to enable encryption
*before*
authentication, or is it?
You're on the right track. My problem isn't the hba file parsing at
all.
My problem is the interaction between the buffering logic and the
encrypted I/O routines. The technical issue is that to make a GSSAPI
security layer independent of SSL you need to invent a whole new
buffering layer. That's a lot of work, and it only buys you the
ability to do both SSL and GSSAPI at the same time. That doesn't seem
worth it.
The code being affected is what's currently configured in column 1 of
hba. The ability to use the new capability requires that SSL *NOT* be
configured in column 1 for the relevant client addresses. In short,
no, it doesn't make sense to make it an option to the gss
authentication method, even though it requires it. If we make it an
option to the gss authentication method it would still need to act
like it was specified in column 1, which would be confusing.
GSSAPI security layers are negotiated after the authentication (or at
least after the start of authentication). There are GSSAPI status
flags that indicate if the security layer is available yet. The
GSSAPI security layer code would check those flags and gss_wrap() or
not accordingly. (-: There's a flush() or two from my original patch
that will need to be added back in, otherwise we'll encrypt a message
that tells the other end how to decrypt messages. Not a big deal. ;-)
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
