http://bugzilla.novell.com/show_bug.cgi?id=1045886
http://bugzilla.novell.com/show_bug.cgi?id=1045886#c19
--- Comment #19 from Andrei Borzenkov
You say that systemd creates a session keyring for the newly created session *before* the user actually logs in (and takes control).
Correct. systemd creates session keyring for every service. Session keyring is inherited across fork/exec so in absence of any explicit action each process started by this service inherits it. If this service was responsible for user login, then all user process will inherit it as well. Please do not be confused by adjective "session". It simply defines lifetime of keyring. It is *NOT* associated with actual login session as we understand it in any way.
If the systemd session key is really required, the login/ssh/... process should setup yet a new session key (belonging to the user) and link to it both _uid_ses and systemd's session key.
How systemd service key comes in picture here? Again - it was added as *unique* per-service keyring; linking it to user accessible keyring will invalidate this use. user processes after logon do not belong to systemd service that started logon manager. In any way. They are not supposed to share keys (at least, I do not see obvious use case).
Is that what pam_keyinit is supposed to do?
No, it is supposed to setup new unique session keyring for every logon session and link user keyring to it. This better matches the adjective "session" IMHO :) Having each user session share the same default session keyring defeats its purpose; then we could just use user keyring itself. As implemented by pam_keyinit, every login session has unique private keyring and also access to shared user-wide keyring. -- You are receiving this mail because: You are on the CC list for the bug.