Skip Menu |
 

To: krb5-bugs@mit.edu
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Date: Fri, 29 Apr 2005 17:34:01 -0700
Subject: Feature Request 2b for 1.5 (or whatever)
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". ;-)
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #3038] Feature Request 2b for 1.5 (or whatever)
Date: Mon, 2 May 2005 13:47:59 -0400
To: rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3KiB
On May 2, 2005, at 12:33, "Henry B. Hotz" via RT wrote:
Show quoted text
> 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).