Skip Menu |
 

To: krb5-bugs@mit.edu
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Date: Fri, 29 Apr 2005 17:32:53 -0700
Subject: Feature Request 2a for 1.5 (or whatever)
Credential cache storage that goes away if you shut the machine down
(or crash it).
------------------------------------------------------------------------
----
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 #3036] Feature Request 2a for 1.5 (or whatever)
Date: Mon, 2 May 2005 13:30:53 -0400
To: rt@krbdev.mit.edu
RT-Send-Cc:
On May 2, 2005, at 12:34, "Henry B. Hotz" via RT wrote:
Show quoted text
> Credential cache storage that goes away if you shut the machine down
> (or crash it).

Kind of like, oh, having the administrator put /tmp into a memory-based
file system?

I'd like to see us add a config-file option to specify the default
directory for credentials, so that a small memory file system could be
used for credentials without requiring that /tmp be that file system.

But not revealing the data after a crash could be tricky on some
systems, unless you do something like encrypting the file system in a
key stored in some magic place in the kernel that is guaranteed to be
wiped before the OS writes out a crash dump.

Aside from making some recommendations about file system setups, you're
basically asking us to invent OS-level functionality across
platforms....
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Subject: Re: [krbdev.mit.edu #3036] Feature Request 2a for 1.5 (or whatever)
Date: Mon, 2 May 2005 11:25:10 -0700
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB

On May 2, 2005, at 10:31 AM, Ken Raeburn via RT wrote:

Show quoted text
> On May 2, 2005, at 12:34, "Henry B. Hotz" via RT wrote:
>> Credential cache storage that goes away if you shut the machine down
>> (or crash it).
>
> Kind of like, oh, having the administrator put /tmp into a memory-based
> file system?

As far as this specific item, yeah.

But. . .

Show quoted text
> Aside from making some recommendations about file system setups, you're
> basically asking us to invent OS-level functionality across
> platforms....

Yeah, possibly. I'd at least like you guys thinking about it. I'm not
underestimating the difficulties, just saying what I'd like (and what I
think other people could use) independent of difficulty.

Same comment applies to 3038. Though I note that the gdb script you
describe is at least harder than changing an environment variable.
"Really hard" is a subjective and context-sensitive term.
------------------------------------------------------------------------
----
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
Please see ticket 3039 which I have generated as a parent to this and
all of the other 2x tickets Hank posted today. At the current time it
is not feasible for the MIT Kerberos team to be considering the
construction of new ccache implementations beyond the CCAPI
implementation. ccache implementations really need to be managed by the
OS vendor and the MIT Kerberos team should be working with vendors in
order to integrate well with their implementations.

On the other hand, some sites do have the desire to add new ccache
functionality which is not supported by the Kerberos libraries. By
adding a plug-in for ccaches. Those sites can add the functionality
they need. The actual implementation of the plug-in could rely on
custom kernel modules or anything else the site desires.