From: Tim Watts <tim.j.watts@kcl.ac.uk>
To: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Subject: Re: Postgresql 8.4 GSSAPI auth with fallback to password prompting?
Date: Mon, 25 Mar 2013 10:39:05 +0000
Message-ID: <51502949.6000903@kcl.ac.uk> (raw)
In-Reply-To: <5c910ac4f9fa4dc78f1ba6747182b671@DBXPRD0310HT003.eurprd03.prod.outlook.com>
References: <514AFB73.6050300@kcl.ac.uk>
<5c910ac4f9fa4dc78f1ba6747182b671@DBXPRD0310HT003.eurprd03.prod.outlook.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
On 24/03/13 18:47, Stephen Frost wrote:
> Tim,
>
> * Tim Watts (tim.j.watts@kcl.ac.uk) wrote:
>> Is it possible to specify GSSAPI auth (with MIT kerberos as the
>> backend) but get Postgresql to fallback to prompting for a password
>> if a kerberos ticket cannot be supplied by the client - eg because
>> the client cannot do GSSAPI or because the client is not part of the
>> kerberos realm?
>
> You're right- it's a 'no'. It would also really degrade the security
> which you get with Kerberos as you'd undoubtably end up with clients
> storing those passwords and using them routinely instead of using
> Kerberos.
>
> Thanks,
>
> Stephen
>
Thank you Stephen, for confirming that.
I would have to respectfully take another point of view: that that
particular judgement is probably better placed with the sysadmin rather
than a blanket decision by the devs.
Reason: Whilst the argument is solid in an ideal world (all clients are
part of the kerberos realm), in reality it means that I cannot gain
partial security improvements and I have to leave it running with PAM
auth which ensures that passwords are chucked around 100% of the time.
My solution regarding scripts is that those *MUST* have a separate user
account that is a member of "role_apps" and uses Postgresql local
authentication. Those are expect to have passwords in config files, so
the domain of attack is limited of the password leaks (one database is
at risk typically).
I definitely do not want user account passwords in config files.
But it would be nice to be able to use kerberos tickets *where
available* and fallback to password-interactive login where not. On
about about 50% of the connections (those where a dev has ssh-ed into a
server that is kerberized) they would not need to retype passwords, so
the temptation to stuff them into .pgpass files would be much reduced :)
Cheers :)
Tim
--
Tim Watts Tel (VOIP): +44 (0)1580 848360
Systems Manager Digital Humanities, King's College London
Systems Messages and Notifications: https://systemsblog.cch.kcl.ac.uk/
Personal Blog: http://squiddy.blog.dionic.net/http://www.sensorly.com/ Crowd mapping of 2G/3G/4G mobile signal coverage
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
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-admin@postgresql.org
Cc: tim.j.watts@kcl.ac.uk, sfrost@snowman.net
Subject: Re: Postgresql 8.4 GSSAPI auth with fallback to password prompting?
In-Reply-To: <51502949.6000903@kcl.ac.uk>
* 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