document current state of Kerberos knowledge

rhel8/kerberos.md

@@ -225,7 +225,14 @@ A self-made PAM module `pam_single_kcm_cache.so` runs at session setup to set:
 - `KRB5CCNAME=KCM:$UID:desktop` to use a shared credential cache for desktop sessions and `systemd --user`
 - `KRB5CCNAME=KCM:$UID:$RANDOM_LETTERS` for text sessions to provide session isolation
 
-Now as the automatically created credential caches by `sshd` (ticket delegation) or by `gdm` (created in PAM by `sss.so`, I guess) end up in a new `KCM` cache with the pattern `KCM:$UID:$RANDOM_NUMBER`.
+I identified so far two cases of the "program flow" in PAM to manage:
+- *TGT delegation* as done by `sshd` with authentication method `gssapi-with-mic`, where a new cache is created by `sshd` and then filled with the delegated ticket
+- *TGT creation* as done by `sss.so` upon password authentication, where a new TGT is created an placed into the `KCM` managed default cache.
+
+The current version of `pam_single_kcm_cache.so` so far handles the first case well, but not so much the second case, as I wrongly assumed that the `sss.so` would also create a new cache.
+
+
+So the current version assumes that the TGT ends up in a new `KCM` cache with the pattern `KCM:$UID:$RANDOM_NUMBER`.
 The credentials therein are now copied over in the newly created or already existing cache. The former, automatic created cache is then destroyed.
 
 Now there is no simple and bullet proof selection of the automatically created credential cache.
@@ -243,8 +250,7 @@ The code you find in [Gitlab](https://git.psi.ch/linux-infra/pam_single_kcm_cach
 
 ## Open Problems
 
-- for NX and su I do not get a copy of the initial cache (or is there an initial cache?), this needs more investigation
-- when getting out of Gnome screen lock it puts the new TGT into the default KCM cache and not necessarily into `KCM:$UID:desktop`
+- `pam_single_kcm_cache.so` needs to deal properly with newly TGTs
 - cleanup of caches, else we might end up in DoS situation
   - `pam_single_kcm_cache.so` could be extended to destroy cache on end of session => not a good idea with AFS and long running background calculations
   - `pam_single_kcm_cache.so` could be extended to optionally destroy all caches at the end of session => useful for `systemd --user`, because that ends after the last user process has ended and would then do a full cleanup. This would also ensure a empty KCM after a clean shutdown.
@@ -269,7 +275,7 @@ Then it is not that easy to reproduce as the problem is best seen in a long runn
 
 I posted a few strange looking `klist` outputs and asked for explanation, but that seamed not yet to have reached someone with intimidate `sssd-kcm` knowledge.
 
-I posted this document, but so far the response was not very helpful. 
+I hope that sharing this document with them will help.
 
 ### Other Options