From: Stephen Frost <sfrost@snowman.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Robbie Harwood <rharwood@redhat.com>
Cc: pgsql-hackers@postgresql.org, Nico Williams <nico@cryptonector.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: David Steele <david@pgmasters.net>
Subject: Re: [PATCH v20] GSSAPI encryption support
Date: Sat, 23 Feb 2019 11:27:51 -0500
Message-ID: <20190223162751.GO6197@tamriel.snowman.net> (raw)
In-Reply-To: <5ec3f734-810e-36e0-030f-af92efe135da@2ndquadrant.com>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
<jlgy38mir81.fsf@redhat.com>
<5ec3f734-810e-36e0-030f-af92efe135da@2ndquadrant.com>
Greetings,
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> I don't know much about GSSAPI, but from what I can tell, this seems an
> attractive feature, and the implementation is compact enough. I have
> done a bit of work on the internal SSL API refactoring, so I have some
> thoughts on this patch.
>
> Looking at the file structure, we would have
>
> be-secure.c
> be-secure-openssl.c
> be-secure-[othersslimpl].c
> be-secure-gssapi.c
> be-secure-common.c
>
> This implies a code structure that isn't really there.
> be-secure-common.c is used by SSL implementations but not by the GSSAPI
> implementation.
be-secure-common.c seems very clearly mis-named, I mean, look at the
comment at the top of the file:
* common implementation-independent SSL support code
Seems we've been conflating SSL and "Secure" and we should probably fix
that.
What I also really don't like is that "secure_read()" is really only
*maybe* secure. be-secure.c is really just an IO-abstraction layer that
lets other things hook in and implement the read/write themselves.
> Perhaps we should rename be-secure-openssl.c to be-ssl-openssl.c and
> be-secure-common.c to be-ssl-common.c.
This might be overly pedantic, but what we do in other parts of the tree
is use these things called directories..
I do think we need to rename be-secure-common since it's just flat out
wrong as-is, but that's independent of the GSSAPI encryption work,
really.
> Or maybe we avoid that, and you rename be-secure-gssapi.c to just
> be-gssapi.c and also combine that with the contents of be-gssapi-common.c.
I don't know why we would need to, or want to, combine
be-secure-gssapi.c and be-gssapi-common.c, they do have different roles
in that be-gssapi-common.c is used even if you aren't doing encryption,
while bs-secure-gssapi.c is specifically for handling the encryption
side of things.
Then again, be-gssapi-common.c does currently only have the one function
in it, and it's not like there's an option to compile for *just* GSS
authentication (and not encryption), or at least, I don't think that
would be a useful option to have.. Robbie?
> (And similarly in libpq.)
I do agree that we should try to keep the frontend and backend code
structures similar in this area, that seems to make sense.
> About pg_hba.conf: The "hostgss" keyword seems a bit confusing. It only
> applies to encrypted gss-using connections, not all of them. Maybe
> "hostgssenc" or "hostgsswrap"?
Not quite sure what you mean here, but 'hostgss' seems to be quite well
in-line with what we do for SSL... as in, we have 'hostssl', we don't
say 'hostsslenc'. I feel like I'm just not understanding what you mean
by "not all of them".
> I don't see any tests in the patch. We have a Kerberos test suite at
> src/test/kerberos/ and an SSL test suite at src/test/ssl/. You can get
> some ideas there.
Yeah, I was going to comment on that as well. We definitely should
implement tests around this.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, peter.eisentraut@2ndquadrant.com, rharwood@redhat.com, nico@cryptonector.com, michael@paquier.xyz, alvherre@2ndquadrant.com, david@pgmasters.net
Subject: Re: [PATCH v20] GSSAPI encryption support
In-Reply-To: <20190223162751.GO6197@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox