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

Re: API differences between Heimdal and MIT

> 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

I agree with empty .k5login as meaning that nobody can log in, but I do
not agree with the unreadable case. I'll elaborate below.

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

I know this workaround exists, but it does not solve the problem. The
problem is that Heimdal dictates the permissions I of users' home
directories. I find that unacceptable (especially since the access is as
broad as world-listable) behaviour and think it's a misfeature. We (at our
lab) also came to the conclusion that having world-listable home
directories is unacceptable. The reasoning was that users will not
remember to "fs setacl system:anyuser none" *all subdirectories* of their
home directory. So in effect, we would not only have $HOME world listable,
but all its subdirectories as well.

Back to the matter of .k5login. I do not have an unreadable .k5login. It's
not even empty. It just happens to reside on a filesystem, where root is
not allowed to access it. I would live with giving root (or rather sshd,
xdm, login, getty etc) AFS tokens (and indeed I already do), but this is
just another workaround and it leaves one case still not worked around:
xscreensaver. We could find no way of making xscreensaver work correctly
with Heimdal's requirement of .k5login being accessible - except that
symlink workaround. Xscreensaver works fine, but if the AFS tokens expire
before the user logs in again... Sorry, pal, no logins for you any more.
This is what we wanted to change.

A lot of our users leave their machines on during nights and weekends,
using the time to make some computations which take hours or days. They
also do these interactively and we do not think that a technical
(solvable!) difficulty is a justifiable reason to impose a change of habit
for users (i.e. not doing them interactively but use same batch job system
or something).

As you probably already read, I solved the problem by adding those two "&&
ret != EACCES" into kuserok.c, so we're fine even if the consensus here is
this is the wrong way to go. I am not trying to forcibly push this change,
so if you decline, it's ok. We'll just keep patching Heimdal all the time.
(Not that I'd like to do that.)

Another way to go would be to let the caller decide whether EACCES is
treated like empty or non-existent .k5login. But that might mean changing
the function call or something equivalent, which probably is not a good
idea.

Actually, I think that just making xscreensaver/PAM skip the whole
krb5_kuserok() call would be best solution for us. What security
implications does that imply? Since the principal is already
authenticated, there is not much point in re-checking .k5login anyway. The
only point of xscreensaver asking the password is to check whether the
being hitting the keyboard is the same guy who locked the screeen. This
can be done without krb5_kuserok(), if i'm correct.

-Juha

P.S. How similar a name you have... =)

-- 
                 -----------------------------------------------
                | Juha Jykk, juolja@utu.fi			|
		| Laboratory of Theoretical Physics		|
		| Department of Physics, University of Turku	|
                | home: http://www.utu.fi/~juolja/              |
                 -----------------------------------------------
J('j۫xZWM:}}ߴM
=PslSק<yi'*')('j۫x ="4DE^Ȩi<kASb@P{9|x@؀'T(.ReoQYS-ɔ1&[툒_I7<'@Jע%
H5(nkq^om4]o~m4(AͲDDUN