[OpenAFS] 1.6.20 pam_afs_session bug ?

[Benjamin Kaduk]

On Thu, Apr 06, 2017 at 10:05:19AM +0200, Andreas Ladanyi wrote:
> Am 31.03.2017 um 22:18 schrieb Benjamin Kaduk:
> > On Thu, Mar 30, 2017 at 03:53:24PM +0200, Andreas Ladanyi wrote:
> >> Hi guys,
> >>
> >> i tested:
> >>
> >> Ubuntu 16.10, Gnome, Kernel 4.8
> >>
> >> current OpenAFS 1.6.20 from ppa.
> >>
> >> After relogin from screensaver dialog the kerberos tgt and afs service
> >> ticket are renewed but the afs token isnt renewed. There is no
> >> "always_aklog" flag at pam_afs_session.so line in pam common-auth file.
> >>
> >> If i try this relogin procedure with OpenAFS 1.6.18 from the distri repo
> >> the afs token is also renewed.
> > Hmm, to have a new afs service ticket obtained (after the new TGT)
> > would indicate that pam_afs_session is still running and doing
> > something, but presumably failing to actually insert the token into
> > the appropriate PAG.  Unfortunately, pam_afs_session is mostly
> > unmaintained these days (I don't believe that Russ found anyone to
> > take it over), so it seems like the most prudent suggestion would be
> > to see whether always_aklog helps.
> >
> > -Ben
> Now it seems there is the same problem with 1.6.18 and 1.6.20 at Ubuntu
> 16.10 (kernel 4.8) .....
> 
> In both cases the screensaver calls pam and the pam_afs_session setcred
> and setcred is running aklog for the correct AFS user ID.
> 
> If i run aklog manual in the terminal because the afs token time is not
> updated by pam_afs_session then the token time will be updated.
> 
> How is it possible to debug the way from calling pam setcred running
> aklog through the way to PAG ? Could the PAG and content be printed to
> the terminal ?
> 
> At Ubuntu 14.04, kernel 4.4 it seems to be no problem with 1.6.20.

Hmm, this feels more like systemd fallout, the more I think about
it.  (Ubuntu 16.10 is on systemd now, right?)
It seems like a usetul debugging step would be to determin the
process hierarchy when the screensaver is calling into
pam_afs_session, and also what keyring entry is being used to hold
tokens.  (That could then be compared to the keyring entry holding
tokens in the interactive user session.)  IIRC we had reports that
the problem is flipped from what one might expect, namely that the
user's terminals could be started from systemd and lose the login
session, and the screensaver properly updating tokens in the login
session, which just aren't used.  But that's quite a bit of
speculation, of course.

(No, I don't know how to get the keyring entry used for tokens from
the context of a pam module, offhand, sorry.)

-Ben