[OpenAFS] home on afs woes

Russ Allbery rra@stanford.edu
Mon, 09 Jan 2006 15:25:05 -0800


Juha J=E4ykk=E4 <juhaj@iki.fi> writes:

> Seems to me, then, that PAM is lacking proper handling of user
> authorization. It may not be much different from handling authorization
> and authentication together, but looks like having different hooks for
> these different things might be a good idea. Go whine to PAM people? =3D)

PAM is lacking a lot of things, the worst of which being a clear and
complete specification that everyone follows.  The problem is not so much
knowing what it needs as figuring out how to get there from here.
Unfortunately, everyone has implemented PAM, everyone has hacked around
each other's bugs, and there are dozens of different ways of doing PAM
that all sort of work and that are all used in practice.

I'm not sure how you'd practically manage to fix the problem without
introducing a new protocol and a new API that's clearer and more strictly
enforced up-front and making everyone migrate, something that would most
likely take a decade.

I'm not particularly optimistic about making significant changes to PAM at
this point.  For the time being, we probably have to live largely with
what we've got.

> As what comes to various other things discussed under the topic, the
> first solution I came up with was to add the sshd host to PTS, and give
> rl to this principal, but sshd *leaks* this token to the user. Is this
> actually a PAG problem?

sshd won't leak this token to the user if your PAM setup is appropriate.
You have to make sure that the user is put into their own PAG as part of
the session initialization process, even if they don't get a token.

> [Russ: the earlier problem on debian-devel was indeed related to the
> aes keys, so thanks for that, too.]

Ah!  Thank you for saying!  I never would have guessed that, and now I'll
know for the future.

--=20
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>