zimoch/Controls-docs
0
0
Fork 0
forked from Controls/gitea-pages
Code Pull Requests Actions Activity

add the "systemd --user" story

Browse Source
This commit is contained in:
buchel_k
2022-10-05 09:36:03 +02:00
parent b5bb0e05ea
commit 7d5f606136
1 changed files with 11 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rhel8/kerberos.md
+11
View File
@@ -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.