[Bug 1852470] Re: default krb5 configuration does not request tgt for local users

[Russ Allbery]

Thomas Schweikle <1852470 at 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 (rra at debian.org)              <https://www.eyrie.org/~eagle/>

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to libpam-krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1852470

Title:
  default krb5 configuration does not request tgt for local users

Status in libpam-krb5 package in Ubuntu:
  New

Bug description:
  default libpam-krb5-config does not request tgt for local users if
  kerberos is available. But it should if a remote user matches the
  local one.

  auth	[success=3 default=ignore]	pam_krb5.so minimum_uid=1000
  auth	[success=2 default=ignore]	pam_unix.so nullok_secure try_first_pass
  auth	[success=1 default=ignore]	pam_sss.so use_first_pass
  auth	requisite			pam_deny.so
  auth	required			pam_permit.so
  auth	optional			pam_cap.so 

  right after logging in I'd suspected 'klist' to exaust:
  #klist
  Ticket cache: KEYRING:persistent:1000:1000
  Default principal: user at REALM

  Valid starting     Expires            Service principal
  11/13/19 18:45:48  11/14/19 04:45:48  krbtgt/REALM at REALM
  	renew until 11/20/19 18:45:43

  But it just does:
  #klist
  klist: Credentials cache keyring 'persistent:1000:1000' not found

  The bad thing behind: non of the further actions done while logging in
  would succeed, because not ticket would be available.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: libpam-krb5 4.8-2
  ProcVersionSignature: Ubuntu 5.3.0-22.24-generic 5.3.7
  Uname: Linux 5.3.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Nov 13 18:36:27 2019
  InstallationDate: Installed on 2019-09-09 (65 days ago)
  InstallationMedia: Xubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  SourcePackage: libpam-krb5
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libpam-krb5/+bug/1852470/+subscriptions