[OpenAFS] home on afs woes

[Russ Allbery]

Juha J=E4ykk=E4 <juolja@utu.fi> writes:

> Debian's pam_krb5.so (where does this originate from?)

http://www.squishy.cc/software/pam-krb5/

> Will leak tokens (not create a PAG) when authenticating with pubkey

This isn't a problem that pam-krb5 should be solving; instead, it should
be dealt with in a session module like libpam-openafs-session.  The latter
is currently not working quite the way that one would want; it should
always create a PAG regardless of whether it can obtain tokens or not.
This is something I plan on looking at when this is all overhauled with
the 1.4.1 packages; since that's going to require substantial work, I
don't really want to go through all of the testing twice.

> Does not get tokens when given the password pam_unix.so uses

Well, yeah.  :)

> Gets tokens when authenticating with gssapi
> All this works no matter how sshd is configured

> Debian's pam_krb5.so also gets the tokens when authenticating using
> kerberos password IF AND ONLY IF the following sshd config variables have
> the following values:

> PasswordAuthentication yes
> ChallengeResponseAuthentication no
> UsePrivilegeSeparation no

Are you using the version in unstable or the version in stable?

The version in unstable works fine with privilege separation.  It still
doesn't work with ChallengeResponseAuthentication, but the version in
Subversion does; I need to double-check with Sam about uploading it.  It
has a workaround for OpenSSH's bizarre way of calling PAM which breaks the
Debian PAM mini-policy; Sam wasn't particularly happy about working around
this, but I think it's a necessary evil for the time being.

> BOTH these modules need Douglas's pam_afs2.so to make sure someone
> creates the PAG. Otherwise things get messy, like noted in earlier posts
> by various people.

I expect that for the 1.4.1 package set I'll either fix
libpam-openafs-session or just replace it with pam_afs2.so, depending on
which looks easier to maintain.

> Also, with RedHat's pam_krb5.so one can change the ticket lifetimes to
> something different than the realm default. With Debian's this is not
> possible (at least there is nothing about it in the docs).

It's not currently possible, no.  Why would you want to do this, out of
curiosity?

I'm hoping that the new profile library support in upcoming versions of
MIT Kerberos will make handling some things like this much easier,
although I'm not sure I understand the use case of this particular
feature.

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