[OpenAFS] home on afs woes

[Sergio Gelato]

* Juha J=E4ykk=E4 [2006-01-11 13:19:57 +0200]:
> > > I would have thought pam_krb5.so [1] does this by itself, but
> > It's only a PAM module for Kerberos.  It doesn't know anything about
> > AFS.
>=20
> I disagree. From its README:
>=20
> o tokens
>   Create a new AFS PAG and obtain AFS tokens during the authentication
> phase.  By default, tokens are obtained for the local cell (and the cell
> which  contains the user's home directory, if they're not the same).
>=20
> Except that, like I said earlier, it seems to rather inherit the PAG from
> its parent. Perhaps I need to investigate it further. Or perhaps it fails
> to create the PAG when doing ssh/GSSAPI.

If you're using privilege separation in OpenSSH, the setpag() that's
done in the authentication phase may not affect the user session (unless
they've managed to make that process a descendant of the one in which
the authentication takes place, or possibly unless the "multithreaded
sshd" hack is used). It's safer to setpag() in the session establishment=20
phase. Doing it in both places may waste a few PAGs, but should otherwise=
=20
be OK.

I've just had a quick (possibly too quick) look at a recent RH pam_krb5
snapshot. The setpag() is called from tokens_obtain(), which is called
=66rom both auth.c and session.c. There are several conditions which can
cause pam_sm_open_session() to return without calling tokens_obtain();
some of these execution paths return PAM_SUCCESS, so marking the module
as "required" instead of "optional" won't help. I'm afraid one needs to
patch the code to make it setpag() very early into pam_sm_open_session(),=
=20
even if no token is going to be obtained (e.g. because the user has no
Kerberos credentials). This doesn't look terribly difficult to implement.

Red Hat's pam_krb5 is not alone in having this problem;=20
see Debian bug #264902.

> > AFS doesn't do AES, at all.  If you do have a DES key for AFS, I don't
> > see why that aklog wouldn't work, but it's also fairly old.  Soon we'll
>=20
> Well, I do and it does not. I suppose it does not like even the user
> having an AES key.

Maybe it's linked against an older libkrb5 which can't cope with an AES
TGT? My current KDC doesn't support AES (I'll upgrade some other day),
so I can't easily test this yet. On the other hand, Debian sarge's
libkrb53 package is based on MIT 1.3.6, which supposedly can handle
aes128 and aes256...

Is there a Debian bug number for this problem? I couldn't find it.

> > for putting your parent process in a PAG (and for right now
> > libpam-openafs-session even relies on it), but it's not the default.
>=20
> Is this again due to the differences between MIT and Heimdal that we need
> to use an additional AFS module beside plain kerberos? Heimdal kinit does
> everything I need, except the PAG. Or does it do the PAG too well?

Heimdal kinit doesn't set the PAG (you are supposed to pagsh first), but
that's a command-line tool, not a PAM module.

[...]=20
> I.e. kinit replaced the token of the parent xterm. Actually, it replaces
> all the tokens of all the processes in the same X session.=20

That's because all those processes are in the same (explicit or implied) PA=
G.=20
On most systems, explicit PAGs are represented as a pair of group IDs, so t=
he
"id" command will tell you which PAG a process belongs to; there is no
need to guess.