5

I have a Linux server using Kerberos for user authentication, and AFS for user homes. When I log into the machine with a forwardable Kerberos ticket, (I suppose) PAM takes care of my AFS authentication too, so I automatically get access to my AFS home after login.

Let's say I log in, and I create a screen session and start an application in it. Then I detach my screen session, and log out from the machine. My Kerberos ticket gets dropped automatically, so my screen session running in the background and the application running in it doesn't have access to my AFS home anymore. This is normal, and it's good as it is.

Next time when I log into the machine, how can I "provide" my already running screen session and the application running in it (the processes themselves) with a new Kerberos ticket and make it able to access my AFS home again without having to restart it?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
PDani
  • 675
  • 1
  • 6
  • 15

2 Answers2

5

You should be able to attach to the screen session, create a new window/'screen' inside of it (with the default config, you can do this by pressing C-a C-c), and just run kinit && aklog. You do not need to run this "inside" the existing running applications or anything like that; you just need to run it somewhere within the same screen session. After that, you can detach the screen and logout, and the screen session should still have your credentials (until they expire; you can use krenew to keep them going for a big longer, but not forever).

A more detailed explanation of what's going on, if you want to know. I'm assuming you are logging in via ssh and PAM is being used, but the same general process works for other setups, as well:

When you first login, PAM assigns you a PAG (a kind of container for your AFS tokens), and runs something that is somewhat equivalent to kinit and aklog to give you AFS tokens inside that PAG. Your shell is then run inside that PAG, so everything that you run in that shell is associated with that PAG and its credentials. That includes the screen session you created.

When you logout, the PAM configuration says to destroy your credentials, which means it destroys the AFS tokens associated with that PAG. That's why the screen session loses credentials and loses access to your home directory: the tokens for that PAG have been destroyed.

Later on, if you login again, you're assigned a new separate PAG, and again you get AFS tokens. The old screen session is still associated with the other PAG, the one where the tokens are destroyed. So if you attach to that screen session, and run kinit and aklog somewhere inside of it, that will create new tokens that are associated with the old PAG from the first time you logged in. You can then detach from the screen session and logout, and the tokens in your current PAG will be destroyed. But the PAG for the screen session is untouched, since neither PAM nor anything else knows about that PAG anymore. So the tokens for it will continue to be valid until they expire.

adeason
  • 155
  • 6
2

The "right" answer is to use something like krenew or kstart to monitor your screen session and make sure it has a valid tgt and afs token. Most sites will allow you to renew your ticket for up to 7 days.

However, that's not the question you asked. The ticket part is easy. The environmental variable KRB5CCNAME stores the location of your kerberos ticket. Generally it looks something like this

KRB5CCNAME=FILE:/tmp/krb5cc_7472_lIwDv27056

So poke around in the /proc system and find the value of KRB5CCNAME for your screen process and copy your existing ticket to that file location.

The AFS token part is much trickier, if you can get the screen process to somehow run aklog after you copy the ticket, that is the most straightforward solution.

There are tools for extracting and setting tokens. gettoken and settoken, but I know of no straightforward way to use them to set the token for an arbitrary process. AFS tokens are stored as part of the process data in the kernel. That's why you see the funny high numbered groups when you use the groups command on a machine using AFS.

Fred the Magic Wonder Dog
  • 8,889
  • 1
  • 26
  • 32
  • Thanks for your answer! Unfortunately, I cannot make the process run aklog, as it is a compiled binary, and it would be too complicated to touch the source, recompile it, etc, especially because I don't have the ownership of these servers, so deployment would be also complicated. In fact, if I could do that, I could probably run kinit too, which would solve the issue, but I can't. So you're saying there's no way to pass the current AFS token to a running process? Thanks again, Daniel – PDani May 10 '14 at 07:46
  • There is always a way, it's just a matter of how much code you're willing to write and whether you have root access. I know of no way to do it using standard tools and even with the unstandard tools I know of I'm not sure if the AFS api supports it. – Fred the Magic Wonder Dog May 10 '14 at 15:46