On a regular linux machine, when I use sudo -s as a normal user, I become root but HOME still points to ~user, so every admin has his own environment etc. (this is without env_reset or always_set_home set).

On a system where the home directories live on an AFS file system, this also works, if the environment variable KRB5CCNAME is preseved, as root can read this file in /tmp.

But if I use sudo on such a system to change a local non-root user (e.g. the dedicated user for a certain service), the new user cannot access the kerberos cache (as it is owned by the old user and has mode 600). But if I unset KRB5CCNAME && kinit user && aklog && exec bash, I have access to my environment again.

So the question is: Is there a clean way to make sudo take the kerberos tickets that I had before and add them to the kerberos ticket cache of the new user?

  • Do you want access to your original user's Kerberos Cache? Or do you want the new session as the non-root user to have AFS tokens from the original user? – jsbillings Aug 10 '12 at 13:08
  • Either would work. I guess granting access to my cache to other users might be more difficult security-wise, so I am fine with my tickets being copied. – Joachim Breitner Aug 10 '12 at 13:50
  • Well, the question I'm really asking is do you need the Kerberos tickets for some other non-AFS function, or do you just want to run a session as a new user with access to your AFS files as the old user? AFS tokens are stored in the user's PAG, while the kerberos cache can be easily copied around. – jsbillings Aug 13 '12 at 13:56
  • AFS access is enough. – Joachim Breitner Aug 13 '12 at 14:00

I don't believe there's any current support for this in any of the Kerberos PAM modules that I'm aware of. I can see how it could be implemented, though; there's nothing inherently impossible about it. Basically, pam_krb5 would need to gain code to open a ticket cache pointed to by the current KRB5CCNAME, iterate through it, and copy each ticket found into the newly-created ticket cache after initial cache setup.

This would need to be a non-default option, since you would be giving away your credentials to the target user (including to anyone else who can become that user), which is potentially dangerous.

If you need an immediate solution, consider using ksu instead if you don't need all of the power of sudo. ksu already has support for keeping the current Kerberos ticket cache (at least in the MIT Kerberos version).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.