On 1063561575 seconds since the Beginning of the UNIX epoch
"Greg A. Woods" wrote:
>

>In fact if you look at those programs you'll find they many of them do
>have direct support for each of crypt(), krb_verify_user(),
>pam_authenticate(), auth_call(), etc.  (see xdm/greeter/verify.c, for
>example, which supports everything but S/Key directly it seems).
>
>Even CVS (for its stupid pserver protocol), includes such direct support
>of at least Kerberos, as well as of course crypt().
>
>Like I say above:  read some more code!
>
>Even a grep for the obvious function names in the obvious places would
>have verified what I said initially to have been correct.

The rather obvious fact that my Kerberos 5 password did not actually
let me log in via xdm(1) was the first clue that it didn't have
support.  I tend to trust that a little more than reading the code.
A grep for the obvious function names in the obvious places was
the naive approach that I first took when trying to get xdm to DTRT
w.r.t. krb5 last year.

Luckily, though, you'll actually find if you examine the code that
it was written against an old beta version of MIT krb5 and does
not actually build let alone work with anything recent.  So the
grep method or even a simple examination of the source without a
reasonable knowledge of the Kerberos 5 APIs is useless.

Perhaps the problem is that all the other projects get their Kerberos
5 support in xdm by using either PAM or BSD Auth and so there is
little impetus for the XFree86 developers to add direct support
for Kerberos 5.

All of the Kerberos 5 bits in the xdm in our source tree are in
support of kerberised X connections and defining the right bits to
get it to build will turn on all manner of broken code in the rest
of the tree (same old API issue.)

If you want it to work, please check out the patches that I made for
it:

	http://www.imrryr.org/~elric/hacks/krb5/xdm-src.tar.gz

xlockmore has a similar story, works with MIT but not Heimdal.

Looking at the CVS code [again in the NetBSD source tree]:

$ find . -name \*.c | xargs grep krb5
./src/server.c:#   include <krb5.h>
./src/server.c: krb5_context kc;
./src/server.c: krb5_principal p;
./src/server.c: krb5_init_context (&kc);
./src/server.c:     || krb5_parse_name (kc, ((gss_buffer_t) &desc)->value, &p) != 0
./src/server.c:     || krb5_aname_to_localname (kc, p, sizeof buf, buf) != 0
./src/server.c:     || krb5_kuserok (kc, p, buf) != TRUE)
./src/server.c: krb5_free_principal (kc, p);
./src/server.c: krb5_free_context (kc);

Well, it has krb5 functions in it---so it must support Kerberos 5
passwords, right?  Well, actually those functions are specifically
in support of gserver and deal with kerberised connections not accepting
Kerberos 5 passwords.

If you look at src/server.c line 5518, you'll find check_password()
which from my initial examination supports only CVS specific
passwords (via check_repository_password()) and standard UNIX
passwords (starting on line 5543.)

>In fact if you look at those programs you'll find they many of them do
>have direct support for each of crypt(), krb_verify_user(),
>pam_authenticate(), auth_call(), etc.  (see xdm/greeter/verify.c, for
>example, which supports everything but S/Key directly it seems).

The xdm/greeter/verify.c in our source tree does not support Kerberos 5,
only Kerberos 4.  So that leaves it supporting only half of the auth
methods that login(1) supports.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/