[16917] in Kerberos_V5_Development
Re: Obtaining a TGT without unrestricted access to password.
daemon@ATHENA.MIT.EDU (Guido =?iso-8859-1?Q?G=FCnther?=)
Fri Jun 17 13:03:16 2011
Date: Thu, 16 Jun 2011 08:44:51 +0200
From: Guido =?iso-8859-1?Q?G=FCnther?= <agx@sigxcpu.org>
To: Russ Allbery <rra@stanford.edu>
Message-ID: <20110616064451.GA20569@bogon.sigxcpu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <877h8ma7jc.fsf@windlord.stanford.edu>
Cc: David Woodhouse <dwmw2@infradead.org>, stefw@collabora.co.uk,
krbdev@mit.edu, gnome-keyring-list@gnome.org
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Wed, Jun 15, 2011 at 06:28:55PM -0700, Russ Allbery wrote:
> David Woodhouse <dwmw2@infradead.org> writes:
>
> > I'm trying to implement automatic renewal of Kerberos tickets during the
> > lifetime of a user's session.
>
> > The user's password is learned at login time and stored within the
> > gnome-keyring dæmon.
>
> Why don't you just obtain renewable tickets and renew them instead of
> storing the password in memory?
What krb5-auth-dialog is often used for is:
* auth offline (e.g. with cached password)
* do stuff
* fire up company vpn
* acquire Kerberos credential
* auth to smtp/imap/etc.
* kill vpn
* ...
I'm not sure if this is what David wants to achieve but if so couldn't
we just move the auth part of krb5-auth-dialog into gkr keeping the
notification parts and plugins of krb5-auth-dialog separate? We could
then use krb5_get_init_creds_password with our own prompter and use the
password if available.
Cheers,
-- Guido
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
