6

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?

Improve this question
4
  • 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? Commented Aug 10, 2012 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. Commented Aug 10, 2012 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. Commented Aug 13, 2012 at 13:56
  • AFS access is enough. Commented Aug 13, 2012 at 14:00

1 Answer 1

Reset to default
2

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

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.