* Juha Jäykkä [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. > > I disagree. From its README: > > 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). > > 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 phase. Doing it in both places may waste a few PAGs, but should otherwise 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 from 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(), 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; 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 > > 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. > > 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. [...] > 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. That's because all those processes are in the same (explicit or implied) PAG. On most systems, explicit PAGs are represented as a pair of group IDs, so the "id" command will tell you which PAG a process belongs to; there is no need to guess. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
