On Mon, Nov 29, 2004 at 03:29:59PM +0100, Pavel Cahyna wrote:
> Hello,
> 
> On Sun, 28 Nov 2004 22:52:47 +0000, Tillman Hodgson wrote:
> 
> > This, in a
> > Kerberos environment, pam_krb5 is a stop-gap measure.
> > 
> > I like PAM. However, pam_krb5 doesn't do what you seem to think it does
> > ;-)
> 
> Say there is a screen-locking program like xlock or xscreensaver,
> which requires a password to unlock the screen. Isn't pam_krb5 the right
> way in this situation to ensure that this password is consistent with the
> password used to login?

Yes, but that's because a screen locking application is one of the only
instances where single-sign-on and ticket caching is /not/ useful. Even
then it has the limitation that it has to be *my* password that's
entered ... what if I want to allow other principals to use my computer
(as they can via network shells and ~/.k5login)? Their password won't
unlock my screen. This isn't really hypothetical: with cross-realm
trusts, I may not even know my local credentials and thus I'd be
required to use my principal from another Kerberos realm.

With traditional network services, pam_krb5 isn't a great solution
because it doesn't understand tockets and that's why I called it a
stop-gap measure. It gets the job done, in it's own fashion, and so I've
used it to kick off a ->Kerberos migration where I knew that an odd
application or two would be retired in the near future anyway.

-T


-- 
There is no reality -- only our own order imposed on everything.
	- Basic Bene Gesserit Dictum