From 7d5f60613665a446a6d588458c406ff259807391 Mon Sep 17 00:00:00 2001 From: Konrad Bucheli Date: Wed, 5 Oct 2022 09:36:03 +0200 Subject: [PATCH] add the "systemd --user" story --- rhel8/kerberos.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/rhel8/kerberos.md b/rhel8/kerberos.md index e095c559..b22c1bc2 100644 --- a/rhel8/kerberos.md +++ b/rhel8/kerberos.md @@ -227,6 +227,17 @@ Maybe we can try to create a solution with `KEYRING` which isolates the interact For the listed use cases above the caches and tickets do not need to survive reboots. If there is something/someone needing `KCM` for some reason, it can be used specifically and privately and will not interfer with the rest of the system. +### How to deal with Systemd --user ? +The `systemd --user` process is started at the beginning of the first session and ends at the end of the last session. And some desktop environments depend heavily on it. + +It might be that "Start of PAM" is good enough, but I expect follwoing problem: +If `systemd --user` is started with ssh or a previous desktop session, the password entry at the desktop login might not update the TGT as PAM is operating on a different cache. +The following might create a solution which might isolate the ssh sessions with individual caches and have one cache for `systemd --user` and all desktop sessions: +The PAM configuration for ssh use a random fixed "Start of PAM" cache, where as for `systemd --user` and the display managers (`gdm` and `lightdm`) the PAM configuration is different as the "Start of PAM" cache is always the same and well known, e.g. `KCM:$UID:systemd--user`. + +I figured out that it is possble to inject environment variables into `systemd --user` with `systemctl --user import-environment` or `systemctl --user set-environment`, but that then affects only newly started software. +Only experiments would show if this is good enought or if some important processes live longer than the desktop session. + ### Red Hat Ticket I have an [ticket](https://access.redhat.com/support/cases/#/case/03280446) open with Red Hat on this case. On the first part I concentrated on the missing session isolation, but it showed that this is the supposed behaviour of a KCM setup.