Comment # 19 on bug 1045886 from Andrei Borzenkov

(In reply to Martin Wilck from comment #18)
> 
> 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.