Comment 4 for bug 1852470

Thomas Schweikle <email address hidden> writes:

> Simple solution: pam_krb5 just only authenticates and some other
> pam_krb5 module has to address the persistent keyring problem as soon as
> pam switches UID space to this authenticated user.

This would break other software that only calls pam_setcred and then
expects to have a ticket cache. Quite a lot of software that expects to
have a ticket cache after authentication never calls pam_open_session.

Worse, some software calls *all* of the PAM stack as root, including
open_session, before changing UIDs. So there is no point in the PAM stack
where you are guaranteed to be running as the target user.

> Or: make root have access to newly created persistent keyrings until it
> switches UID. Would mean to make it possible to switch a root generated
> persistant keyring owner to a user, but not vice versa.

So far as I can tell, there is no way for a single process to have access
to both root's persistent keyring and a user's persistent keyring at the
same time, so I believe this is not possible to do. But if you know of a
way to do this, please do let me know.

> AFAIK it is possible to create the keyring store as root, then change
> the UID of the owner, which handles the keyring store over to the user
> in question.

That would be great -- I have no idea how to do that, though. Do you have
any pointers?

--
Russ Allbery (<email address hidden>) <https://www.eyrie.org/~eagle/>