give 'End of PAM' maybe another chance?
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user