Re: API differences between Heimdal and MIT

[Johan Danielsson <joda@pdc.kth.se>]

Juha Jäykkä <juhaj@iki.fi> writes:

First, the behaviour isn't set in stone. We can change it if you have
a good argument why it should be different.

In 0.7 we changed how kuserok works. Like you've observed, unreadable
(as well as empty) .k5login now mean that nobody can login. The only
case where the local principal check kicks in is when there is no
.k5login at all. This also means that if you create a .k5login, you'd
better include yourself.

> 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
> match_local_principals().

I think the argument is that since we don't know who is allowed to
login, we should deny everyone. 

> 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.

What's the point in having an unreadable .k5login? You should move
your .k5login to a publicly readable directory and put a symlink in
your home directory (assuming you have list rights for system:anyuser
in ~).