give 'End of PAM' maybe another chance?

This commit is contained in:
2022-10-05 09:41:14 +02:00
parent 7d5f606136
commit a3b2ce5fe6

View File

@@ -219,8 +219,8 @@ I assumed that the "End of PAM" solution would be easier to implement, so I opte
## Options for Next Steps
### Try out End of PAM
For the "Start of PAM" experiments I got more into PAM and Kerberos programming with C than I wanted and I think I would get that working in reasonable time.
### Try out Start of PAM
For the "End of PAM" experiments I got more into PAM and Kerberos programming with C than I wanted and I think I would get "Start of PAM" working in reasonable time.
### Try out KEYRING
Maybe we can try to create a solution with `KEYRING` which isolates the interactive sessions and still allows the AFS token renewal to access all caches. This then also needs `renew-afstoken` to care about Kerberos ticket renewal.
@@ -235,6 +235,7 @@ If `systemd --user` is started with ssh or a previous desktop session, the passw
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`.
### Go on with End of PAM experiment
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.