[7822] in Kerberos
Re: destruction of Kerberos credentials upon logout
daemon@ATHENA.MIT.EDU (Sam Hartman)
Wed Aug 21 14:54:01 1996
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: Sam Hartman <hartmans@MIT.EDU>, kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 21 Aug 1996 14:44:56 -0400
In-Reply-To: Ken Hornstein's message of Tue, 20 Aug 1996 15:10:47 -0400
>>>>> "Ken" == Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
>> Experience has shown that it's much more useful to remove the
>> accumulation of unintentionally left Kerberos credentials than
>> to preserve credentials for background jobs. Most people who
>> run background jobs on a regular basis are able to quickly
>> figure out they can copy the ccache and change the environment
>> variable name, or even run their jobs under ksu.
Ken> I understand that reasoning, and I agree with it; however, we
Ken> are trying to make the transition from a non-Kerberos
Ken> environment to one that uses Kerberos as much as possible.
Ken> Anything that helps to ease this transition would be an
Ken> asset, and this is one case that will require some
Ken> retraining. If the credentials stuck around, it would be a
Ken> smoother transition.
It's a fairly hard call. I'm concerned that if the MIT
release contained a configuration option that allowed klogind to be
configured not to destroy credentials on logout, people would use that
option for more than just a transition. Also, I suspect in many
environments, it would be better in the long-run to have a
roughertransition period and to destroy the credentials. Naturally,
some user communities/system requirements don't allow for the
short-term confusion that may be introduced while people learn the new
credential-passing semantics. In such environments, it may be
appropriate to modify the behavior of Kerberos and force it not to
destroy credentials. I just think that it might create more of a
problem than it's worth to make it easy for admins to choose not to
destroy credentials.
I talked to a few people I know who have experience dealing with user
support and to another Kerberos developer. They all agreed that in
many environments, the option would tend to get turned on without a
full understanding of the consequences, and would tend not to get
turned off.
Ken> I'm wondering if there is any interest in making this
Ken> behavior configurable via krb5.conf - something like
Ken> "krb5_retain_ccache" under [login]. The default would be to
Ken> cleanup everything at logout time, but other sites could
Ken> change this behavior if they wanted to.
>> Personally, I think this is a bad idea. However, it's an
>> issue where I certainly don't have a good feeling about how
>> other people stand, so their might be enough support to put it
>> in. I would certainly be willing to agree with an AFS-specific
>> option to avoid destroying tokens on logout.
Ken> Fair enough; what would be a good name for an option such as
Ken> this?
In the same lines as your previous proposal, something like
afs_retain_tokens?
Ken> Something else along these lines - a lot of people here use
Ken> rsh to start X applications on other machines with scripts
Ken> like xrsh or xon; right now rshd destroys the credential
Ken> cache when the process exits. The problem here is that
Ken> there's really not a good method to copy the credential cache
Ken> when running stuff from rsh, and even if we did, it would be
Ken> very difficult to modify all of the programs that use rsh to
Ken> do the necessary copying (some we do not have source to, such
Ken> as AVS). I've got an option like this working now with rshd,
Ken> and it solves a lot of problems.
The problem here is that it's even more inconvenient to
destroy credentials than to copy them when you're using RSH. I agree
that neither is particularly convenient. I would like to think more
about this problem and try to come up with a solution, although I know
from personal experience that simply not destroying the credentials
tends to be the wrong solution. It creates a large mess in /tmp, and
leaves many live credentials around that users never clean up. I
would agree that an afs_retain_tokens option would be reasonable
if/when someone adds code to destroy the tokens to your aklog patch.
However, I would like to find a more general solution to the problem.
Are most of the jobs that are started explicitly backgrounded
or do they background themselves?
Ken> Again, I fully admit that this isn't the best solution, but
Ken> isn't all of life a compromise? :-)
Ken> --Ken
