CVS-tip; SSLmode & Kerberos

Hi,

I've just had some testing done by Magnus Hagander who uses psqlODBC in
a kerberos environment and a couple of minor issues came to light:

- Kerberos authentication (and therefore other features of libpq like
pgpass) can only be used if sslmode !=3D d. This is because the original
CC_connect code is used instead of libpq in this case. Is there any
reason to not use libpq all the time regardless of sslmode (if it's
available of course)?

- sslmode defaults to 'disable'. If libpq is available, 'prefer' would
seem the more secure default option. Any reason we should not change
this as well?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: CVS-tip; SSLmode & Kerberos

Dave Page wrote:
> Hi,
>
> I've just had some testing done by Magnus Hagander who uses psqlODBC in
> a kerberos environment and a couple of minor issues came to light:
>
> - Kerberos authentication (and therefore other features of libpq like
> pgpass) can only be used if sslmode != d. This is because the original
> CC_connect code is used instead of libpq in this case. Is there any
> reason to not use libpq all the time regardless of sslmode (if it's
> available of course)?

Because I don't want to use libpq if it's possible.
The current implementation doesn't need libpq at all except
when you need SSL, kerberos or ipv6 etc connection/authentication.
I don't know what libraries the libpq would need in the future
but it's quite unpleasant for me if the psqlodbc driver can't
be loaded with tha lack of needeless librairies.
In addtion using the native connection has the following 2 points
at least.
1. The driver sets some session default parameters(DateStyle,
client_encoding etc) using start-up message.
2. You can try V2 protocol implementation when the V3 implementation
has some bugs or performance issues.
(personally It's hard for me to test v2 protocol implementation
without using the functionality because I don't have pre 7.4
server personally.)

> - sslmode defaults to 'disable'. If libpq is available, 'prefer' would
> seem the more secure default option. Any reason we should not change
> this as well?

There's no reason other than it's my default.

regards,
Hiroshi Inoue

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Re: CVS-tip; SSLmode & Kerberos

On 14/4/06 01:42, "Hiroshi Inoue" wrote:

> Dave Page wrote:
>> Hi,
>>
>> I've just had some testing done by Magnus Hagander who uses psqlODBC in
>> a kerberos environment and a couple of minor issues came to light:
>>
>> - Kerberos authentication (and therefore other features of libpq like
>> pgpass) can only be used if sslmode != d. This is because the original
>> CC_connect code is used instead of libpq in this case. Is there any
>> reason to not use libpq all the time regardless of sslmode (if it's
>> available of course)?
>
> Because I don't want to use libpq if it's possible.
> The current implementation doesn't need libpq at all except
> when you need SSL, kerberos or ipv6 etc connection/authentication.
> I don't know what libraries the libpq would need in the future
> but it's quite unpleasant for me if the psqlodbc driver can't
> be loaded with tha lack of needeless librairies.
> In addtion using the native connection has the following 2 points
> at least.
> 1. The driver sets some session default parameters(DateStyle,
> client_encoding etc) using start-up message.
> 2. You can try V2 protocol implementation when the V3 implementation
> has some bugs or performance issues.
> (personally It's hard for me to test v2 protocol implementation
> without using the functionality because I don't have pre 7.4
> server personally.)

I'm not suggesting we force the use of libpq, just that the choice of
sslmode does not affect whether or not Kerberos etc. will work. That's
extremely unintuitive given that the two are completely unrelated to the end
user.

One way of course would be to provide a separate option to allow you to
disable libpq, but I don't know if that is the only/best way.

Regards, Dave


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly