[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

API differences between Heimdal and MIT


I was trying to link a linux pam module (namely, libpam-krb5 in Debian
unstable, designed for MIT Kerberos V) against heimdal, but run into some

The problem lies in the behaviour of krb5_kuserok(). MIT returns TRUE, if
.k5login cannot be accessed, Heimdal returns FALSE. In my opinion, MIT's
behaviour is correct and Heimdal's is not. My reasoning, in short, is that
since they both check that the user is trying to log in as oneself (and
return false if this is not the case) if .k5login cannot be accessed.
What's the point in checking this if false is returned nevertheless?

Actually, Heimdal does not even check this ever (lines 202-203, 210-211
and 258-259 of kuserok.c):

    if(ret != ENOENT) 
        found_file = TRUE;

    if(ret != ENOENT && ret != ENOTDIR) 
        found_file = TRUE;

    if(found_file == FALSE)
        return match_local_principals(context, principal, luser);

If .k5login cannot be accessed and .k5login.d cannot either, the first two
if clauses make sure found_file is set to TRUE and
match_local_principals() is never called. In my opinion, the correct
behaviour is (same lines):

    if(ret != ENOENT && ret != EACCES) 
        found_file = TRUE;

    if(ret != ENOENT && ret != ENOTDIR && ret != EACCES) 
        found_file = TRUE;

    if(found_file == FALSE)
        return match_local_principals(context, principal, luser);

There are possibly still other return values that may need to be checked,
but at least EACCES should be interpreted the same way as ENOENT and
ENOTDIR: we could not determine the contents of .k5login, hence we call

I would guess the omission of EACCES comes from the usual assumption that
whoever is calling krb5_kuserok() is either the user itself or root, in
which case EACCES should not happen. But it can and will happen if $HOME
is on AFS and krb5_kuserok() is called before the AFS tokens are obtained.

If this change is not something Heimdal maintainers are willing to make,
would you at least tell me if it will open any security holes? I would
think not - MIT behaves this way anyway.


		| Juha Jäykkä, juolja@utu.fi			|
		| home: http://www.utu.fi/~juolja/		|