Andrew Deason <[email protected]> writes: > Now, if you just mean, "just support kernel keyring ccaches on Linux, > and if you're not using them, then you lose", then okay. Right now I'm > sure I'd try to support at least FILE: ccaches as well, since they are > the easiest in some ways, but at some point we'd just say some ccaches > don't work with this, sure.
I don't think Heimdal supports keyring caches currently, although I may have missed some development there. DIR: caches are also quite useful for implementations that support them if you have to juggle tickets from multiple realms. You can do the same thing with KEYRING: caches, but it's a lot easier to inspect DIR: caches and debug problems. To take a step back, one difficulty I've been having with this whole thread is how you get PAGs if you don't require some sort of PAM-like thing to run during user login. You can't get PAGs through looking at people's ticket cache; the whole point of PAGs is that they *don't* follow UID-based access control (and a lot of AFS applications heavily rely on that feature). People seem to think that the point of pam-afs-session is to run aklog, but that's not true. The main reason why pam-afs-session exists is to create the PAG. If all one had to do was run aklog during login, one could just use pam_exec; there would be no need for a separate module. The PAG management is the hard part. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
