[OpenAFS] Output of tokens command intermittently shows AFS ID

[Simon Wilkinson]

On 25 Mar 2010, at 15:36, John W. Sopko Jr. wrote:

> Does anyone have a clue why the "tokens" command sometimes shows the
> (AFS ID xxxx) and sometimes it does not as shown below? The
> problem is intermittent.
>=20
> The systems are rhel5, openafs 1.4.11, using redhats pam_krb5afs.
> This occurs when ssh'ing to machines. If you just do an
> "aklog" after logging in you always get the (AFS ID xxx) format.

The ID isn't actually used (it's actually a horrible, horrible hack =
between various different abstraction layers which variously represent =
it as a string, and as a numeric ID) - so you don't need to worry about =
the fact that it isn't there. The only thing you'll really lose is some =
information in debugging messages. When prsent, the number should be the =
user's pts ID, and is supplied by userspace when it sets tokens.

Judging from the copy of RedHat's pam_krb5 (2.2.2) that I found in a =
random Google code search, they use the local Unix uid of the user =
obtaining the token to populate this field. If you are obtaining tokens =
as root, then I suspect this ends up being 0, and so you'll appear to =
have no pts ID. This behaviour appears on first glance to be broken.

"Correct" behaviour requires calling out to the ptserver from the PAM =
module. Unless you take the approach of Russ's PAM module, and use =
system() to invoke aklog(), then this means that your PAM module has to =
pull in a vast set of dependencies, from the ptclient suite, to rx, to =
the "interesting" threading libraries used by OpenAFS's database =
clients. It's unlikely that such a PAM module would function reliably, =
so if you want to do token acquiry without forking another process, you =
can't populate the ID number. As noted earlier this shouldn't cause you =
any real problems.

Cheers,

Simon.