help with persistent ccache

[Ben H]

Thanks again Brandon.

Yes I know that the PAM module is linked against libraries pre 1.12 that
don't support the persistent option.  These are different from the system
libraries that sshd is linked against.
I'm going to work on seeing if updating those libraries fixes this, or if I
can use a different PAM module that is using more up to date libraries.

I'll try to update this when that happens, but it may be a while off.  For
now I think we will be reverting to the FILE based cache.


On Wed, Jun 24, 2015 at 3:35 PM, Brandon Allbery <ballbery at sinenomine.net>
wrote:

> Hard to say, but I would expect the keyring interaction to be in the
> Kerberos libraries so a problem at that level might indicate that the
> PAM module is linked against a different version of the Kerberos
> libraries. This would seem unlikely if it is using shared libraries
> (which you can check with ldd).
>
> It is more likely that the correct context for the keyring is not yet
> established when the PAM session stack is run, so it is either creating
> the keyring but in the wrong place (keychain) or getting an error while
> trying to create it. This would be controlled by when sshd runs the PAM
> session stack relative to other parts of session establishment, and
> might depend on details of how the Linux keychain is associated with a
> user process. It could also be related to recent sshd features such as
> sandboxing, where the keyring might e.g. be created inside the sandbox
> instead of in the user session.
>
> (It also would not be the first time that sshd turned out to do things
> slightly incorrectly; in the (somewhat distant) past this has led to
> file ccaches owned by root, for example.)
>
>
> On Wed, 2015-06-24 at 15:27 -0500, Ben H wrote:
> > Thanks for the quick reply Brandon.
> >
> >
> > I don't have this issue if I remove the "default_ccache_name =
> > KEYRING:persistent:%{uid}" and thus default back to the file based
> > cache.  In that case, the cache is created properly on login in /tmp,
> > That would indicate to me that PAM is properly creating a cache.
> >
> >
> > Would this indicate that it isn't the PAM stack not creating the cache
> > or would it more likely be the PAM module not utilizing the keyring
> > properly?  Or perhaps the PAM module doesn't understand how to work
> > with the keyring?
> >
> >
> > thanks.
> >
> >
> >
> > On Wed, Jun 24, 2015 at 3:21 PM, Brandon Allbery
> > <ballbery at sinenomine.net> wrote:
> >         On Wed, 2015-06-24 at 15:10 -0500, Ben H wrote:
> >         > Why is not cached initialized on interactive login and an
> >         additional
> >         > manual
> >         > kinit is required?
> >
> >         This may have nothing to do with keyring ccache, but only with
> >         a
> >         misconfigured PAM stack that is not creating a ccache with the
> >         ticket
> >         from login.
> >
> >         Alternately it could mean that login is running the session
> >         PAM stack in
> >         the wrong context, so the wrong keyring is created. I would
> >         check the
> >         first part before trying to diagnose the second, though.
> >
> >         --
> >         brandon s allbery kf8nh                           sine nomine
> >         associates
> >         allbery.b at gmail.com
> >         ballbery at sinenomine.net
> >         unix openafs kerberos infrastructure xmonad
> >         http://sinenomine.net
> >
> >         ________________________________________________
> >         Kerberos mailing list           Kerberos at mit.edu
> >         https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
>
> --
> brandon s allbery kf8nh                           sine nomine associates
> allbery.b at gmail.com                              ballbery at sinenomine.net
> unix openafs kerberos infrastructure xmonad        http://sinenomine.net
>