[7817] in Kerberos
Re: destruction of Kerberos credentials upon logout
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Aug 20 13:39:11 1996
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 20 Aug 1996 13:33:21 -0400
In-Reply-To: Ken Hornstein's message of Tue, 20 Aug 1996 10:49:49 -0400
>>>>> "Ken" == Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
Ken> I've noticed that the Kerberos login replacement hangs around
Ken> and destroy all of your Kerberos credentials upon logout, and
Ken> it also destroys all of your AFS tokens (if you compile AFS
Ken> support in).
Ken> To me, this seems to violate the principal of least
Ken> astonishment; users expect that backgrounded jobs will still
Ken> run with the same credentials that existed in their login
Ken> session after they logout.
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.
There is a problem with regard to AFS tokens: it's not as easy
to copy them and preserve them for background jobs. I would probably
say that since nothing outside of the PAG that owns the tokens can use
them, leaving the tokens around might be reasonable.
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.
Another problem I have with the current system is the handling
Ken> I have to do this anyway for our site, so I'm wondering that
Ken> if I write this code, is there a chance it would be accepted
Ken> by the Kerberos team? And while I'm on the subject -- if
Ken> I've made a really really cool change to Kerberos that I
Ken> think everyone would benefit from, what's the proper process
Ken> to contribute it?
You should send to krb5-bugs@mit.edu if you want to see it in
the MIT release. If it's useful enough that you feel some admins
might want to patch it into their local sites, feel free to post to
the newsgroup as well. If there are export issues associated with the
patch, then take whatever action you feel is appropriate.
New features tend not to get dealt with as quickly as bugs,
and there are still some cracks in the system that things sometimes
fall through. Often, especially for large patches, we tend to try
and let the person who submitted the patch know if we merge it in.
There really isn't a formal process for deciding a patch shouldn't be
integrated so it's hard to distinguish the following similar states:
no one has had time to deal with merging the patch, everyone thinks
someone else is best to audit the patch, no one thinks the patch
should be merged. Yes, we realize that our bug/change tracking is an
area that could use significant improvement.
Ken> --Ken
