[krbdev.mit.edu #3038] Feature Request 2b for 1.5 (or whatever)

[Ken Raeburn via RT]

On May 2, 2005, at 12:33, "Henry B. Hotz" via RT wrote:
>   Cache storage that is confined to a "login session" or something
> like it.  It should be "really hard" for my ssh session from home to
> interfere with the console session I left running when I went home.
> (Just changing an environment variable does not qualify as "really
> hard".  ;-)

As with ticket 3035, you're talking about things requiring OS-level 
functionality.
If the magic bits are added to an OS, perhaps we can work with them, 
but I don't think we're too likely to write the OS support ourselves.

Then there's the question of how far you take it... it wouldn't take 
huge amounts of effort to write a program that takes a process-id, 
attaches to the process under ptrace, forces a call to dlopen the 
Kerberos libraries if needed, forces a call to retrieve the TGT into 
memory, copies out the TGT, and detaches the process.  Presto, you've 
got the TGT from a process in a different login session.  Writing the 
program might be a little annoying (though doing it as a gdb script 
might not be hard at all), but once it's written, it certainly wouldn't 
be "really hard" to run it.  So if you need this to be "really hard", 
then either you need gdb to not work this way between login sessions, 
or the process can't be allowed to access its own Kerberos tickets 
directly (at least when ptrace is involved).