MacOS X 10.2.2, Kerberos, and Pine

Alexandra Ellwood lxs at MIT.EDU
Wed Nov 20 12:34:01 EST 2002

>Now, if I have already authenticated myself the behavior is the same. If I
>haven't, it's different in a bad way. Instead of launching the graphical
>Kerberos Login window, it tries to get me to authenticate from the
>terminal. Unfortunately, at that point Pine has disabled keyboard input,
>so I can't enter anything. And since Pine is waiting for kerberos
>authentication before continuing, I never get keyboard control back. I
>have to kill the pine process entirely.

KfM 4.5 (included with 10.2), defaults to using a Terminal prompt if 
it is called from an application with a controlling terminal 
(determined by isatty/ttyname).  The reason for this change was that 
using in a multi-monitor situation can be very confusing 
if prompting occurs via a dialog on a separate monitor.

For some stupid reasons, the terminal prompting does not correctly 
save and restore terminal state.  Obviously without proper saving and 
restoring, callers which modify the terminal or use curses will 
prevent the Kerberos Login Library from prompting the user and/or 
become confused by the aftereffects of KLL's prompting.

This problem exists both for your situation and also for folks coming 
in from remote connections -- except that it's worse for remote 
connections because there is no other way of prompting.

We will hopefully be fixing this bug in the next release.  We will at 
the very least stop prompting in the terminal case (ie: similar 
behavior to 10.1.x).

If you want to make sure it gets fixed, please file a bug with Apple 
at the Apple bug reporter <>.  Hint: this 
will help us with the aforementioned "stupid reasons".

>This is with the same Pine source, mind you. Compiling it on 10.1 with
>Kerberos for Macintosh 4.0.x results in a Pine which invokes the graphical
>login utility. Compiling it on 10.2 with whatever kerberos comes with that
>results in a Pine which attempts to use terminal i/o and fails.

If you want pine to prompt with the dialog (and return "no tickets" 
errors on remote logins), you can just modify the sources so that 
isatty (stdin) or isatty (stdout) returns false before you call into 
Kerberos, and then restore stdin and stdout afterwards.  This will 
trick KLL into thinking you don't have a controlling terminal so it 
will try the dialog (or return "no tickets" if it can't display the 

Hope this helps,

Alexandra Ellwood                                               <lxs at>
MIT Information Systems                     

More information about the krbdev mailing list