Mechanism extensions and the GSSAPI

Christopher cmaxwell at
Mon May 3 16:20:17 EDT 2004

On Mon, 3 May 2004, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at> writes:
>     Nicolas> On Mon, May 03, 2004 at 02:26:54PM -0400, Sam Hartman
>     Nicolas> wrote:
>     >> And yet none of these are useful if we are specifying at the
>     >> shim layer.
>     Nicolas> Specifying at the shim layer.  I'll have to think about
>     Nicolas> that.
> If we don't specify at the shim layer, then we cannot depend on the
> shims being present.  That means that people are forced to code to the
> ioctls, which makes extensions hard to use.

Maybe this is oversimplistic, but why not provide the shims as
library/source to be linked into the application that deal with the
ioctls below the applications view of them?

It does mean that people are coding to the ioctls, but they won't
realize it.

It also means that there cannot be unresolved symbols due to version X
missing shims ... the worst case would be a failed ioctl.

> ALso, while I'm willing to agree that an ioctl approach is reasonable
> for C, I'm much less convinced that it is right for Java or some other
> language binding.

If it is hidden behind local shims, is this still an issue?  (I am
unfamiliar with Java)  It will mean maintaining a collection of
per-language shims, but on the other hand it forces everyone to use the
same well-known shims...

> GSSAPI has always been specified at an API layer.  AS such you should
> specify extensions the same way.

More information about the krbdev mailing list