Thomas Schweikle <1852...@bugs.launchpad.net> 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 (r...@debian.org) <https://www.eyrie.org/~eagle/> -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1852470 Title: default krb5 configuration does not request tgt for local users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpam-krb5/+bug/1852470/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
