[20298] in Kerberos_V5_Development
Re: Not building kcpytkt/kdeltkt
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Mon Aug 2 18:58:36 2021
Message-ID: <202108022258.172MwQGD004906@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: krbdev@mit.edu
In-Reply-To: <31512a32-59bc-14ea-52a0-10262c75cc44@mit.edu>
MIME-Version: 1.0
Date: Mon, 02 Aug 2021 18:58:24 -0400
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>That was before my time, so I don't know if it was deliberate or an
>oversight. (I've looked over list archives in the past and never found
>anything conclusive.) But I'd rather not add them at this point if
>there isn't a real need for them. Some of the use cases for them can be
>met by kinit -S or kvno --out-ccache.
Fair enough, although I don't think either of those really replicate
the specific functionality exercised by krb5_cc_remove_cred()? Although I
don't think I've ever really wanted to remove a specific credential from
a cache. I am racking my brain and I cannot come up with a reason to.
A quick grep over the source code suggests to me other than kdeltkt,
the only other way (assuming an application doesn't specifically call
that function) for krb5_cc_remove_cred() to be called would be for
krb5_cc_set_config() with a NULL data argument, which the MIT source code
does not do. And, actually, maybe that's ONE possible use case? I could
imagine a few weird cases where I might want to delete configuration
information stored in the cache. I will be the first to confess this
is not a strong reason.
--Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
