Integration of k5start/krenew functionality

Greg Hudson ghudson at MIT.EDU
Sun Aug 2 23:47:45 EDT 2009

On Sat, 2009-08-01 at 18:33 -0400, Ken Hornstein wrote:
> If the goal is to support AFS, then I think you should go whole-hog.

AFS support is not a primary goal.  Given that krenew and k5start will
continue to be maintained externally, I am now wondering if perhaps the
project scope should be narrowed substantially to limit the amount of UI
real estate used.  So I am thinking of dropping the krenew use case,
eliminating the aklog-shaped external program hook, and supporting only
one style of k5start use case--for example, only operation as a process
wrapper, and not as a background process or check-and-renew utility.

> It's just easier (I have enough time getting the levels of quoting
> right when using multiple levels of shell interpretation .... I can't
> imagine what an unsophisticated user would do).

I don't want to go too deep down the conversational rabbit-hole here,
but process wrappers like pagsh and k5start generally use exec() rather
than passing their arguments to a shell, so they don't add multiple
levels of shell interpretation.

The other Ken wrote:
> Can we do it with a tiny plugin module that can either be installed or
> not depending on whether you need the AFS support,

I am reluctant to add any build dependencies of any kind on AFS, because
AFS depends on krb5.  We already have a bit of a loop with login.krb5,
but that will be fixed by unbundling the applications.  I don't even
know how Debian manages the existing dependency loop, but it can't be

Finally, in regards to coupling a ccache to a keytab at the library
level: I have even more reservations on this front after thinking about
it further.  The as-req code path is fundamentally more complicated than
the tgs-req code path because of the open-ended nature of the preauth
framework.  For example, you might need pkinit to perform an as-req, and
pkinit relies on OpenSSL, which does not want to be linked into the same
process as GPL'd code.  I'm very uncomfortable with the idea of
krb5_get_credentials() potentially performing an as-req at this time.

More information about the krbdev mailing list