From: Robbie Harwood <rharwood@redhat.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Michael Paquier <michael.paquier@gmail.com>,
        PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH v9] GSSAPI encryption support
In-Reply-To: <20160331194556.GA134261@alvherre.pgsql>
References: <20160331194556.GA134261@alvherre.pgsql>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Thu, 31 Mar 2016 16:54:57 -0400
Message-ID: <jlgtwjm4bby.fsf@thriss.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

> Robbie Harwood wrote:
>> Michael Paquier <michael.paquier@gmail.com> writes:
>
>> > +   iov[0].iov_base =3D lenbuf;
>> > +   iov[0].iov_len =3D 4;
>> > +   iov[1].iov_base =3D output.value;
>> > +   iov[1].iov_len =3D output.length;
>> > +
>> > +   ret =3D writev(port->sock, iov, 2);
>> >
>> > writev and iovec are not present on Windows, so this code would never
>> > compile there, and it does not sound that this patch is a reason
>> > sufficient enough to drop support of GSSAPI on Windows.
>>=20
>> Um.  Okay.  I guess on Windows I'll make two write calls then, since the
>> only other option I see is to hit alloc again here.
>
> Hmm, I wouldn't push my luck by using writev here at all.  We don't use
> writev/readv anywhere, and it's quite possible that they are not present
> on older Unixen which we still support.
> http://pubs.opengroup.org/onlinepubs/009695399/functions/writev.html
> says writev was introduced in "issue 4 version 2", which AFAICT is the
> 2004 version, but our baseline is SUSv2 (1997).  So it's definitely not
> workable.

Understood.  What do you suggest instead?  To give some context here,
writev() is being used here because I have a GSSAPI payload that is
(effectively) opaque and need to include length in it.  The only
alternatives I can see are either allocating a new buffer and reading
the payload + length into it (incurs additional memory overhead), or
calling a write/send function twice (incurs syscall overhead at
minimum).

>> > +   {
>> > +       {"gss_encrypt", PGC_USERSET, CONN_AUTH_SECURITY,
>> > +        gettext_noop("Require encryption for all GSSAPI connections."=
),
>> > +        NULL,
>> > +        GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
>> > +       },
>> > +       &gss_encrypt, false, check_gss_encrypt, assign_gss_encrypt, NU=
LL
>> > +   },
>
> Why is this marked NOT_IN_SAMPLE?

Well, because it's not something that's supposed to be set in the file
(and indeed, you can't set it there, if I understand
GUC_DISALLOW_IN_FILE).  It's used only as a connection parameter, and I
use its presence / absence for the client and server to negotiate GSSAPI
encryption support.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJW/Y6iAAoJECUy+RdqlaRC/UoP/iG8G3Q6Vj7sXD+DMonJWKfM
aFyqOIFXky5Y0YjTIOmRmkuJepuHNO0h3Ef8ldIJRY5Ynn9GZGeYHLF5xYov1j4u
AtbiXkHNuOax/R58XwXuKKTDVQqfvUrpPvuGAhfzvN4z+V8mYmcEbjGwFh/lUlDf
Pv5kDREnRkyoLxbFi9yt4E9MjVBZQOHkldkJ/W8+bPCDrjFpfx7T+te3R2RBtMsg
zJVsZ8j4qlD9XymTmFrMQkg86OfyiQr5h9xiXPZd0+W0yZo+hYSH7mNOB6afNBd2
KEY8aPTHKv1gJI3T8bNEm06ATnFl5zif5437TT9QIoBRqDwfhogWH92O7MGoXMTD
Pxto6z9DiK90/537XIeaTSTA51hODTJG1SdaTdcl7Mso3xyDgresMN5sIQs5uiGX
1YGgFkakVXXxmKR+5fqmdz2mw4T5L21y2oLtJJbzty/NsehcJ4sCDwkUeCMSNa9b
/V3fKQPp+ypqZGmsFIFZwCnvJOGRwfVl+2dmOYwo0XM1OckzyCAPFGskyi9MM0lD
PqIxVOTb/LwqxS2KJWH4QrUTfy2zorOm3hfGWX6LRNZY2ddsyuCcW8zaUPtCbdZX
D3C2KBxr9xGThel3Ptx3HsdY3fpMKrBS74873BdnHfy0N/zUWkR8tBbiw92cv5Ui
gP/hj5etjgAkD8TI5Uw3
=OjKc
-----END PGP SIGNATURE-----
--=-=-=--