[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heimdal and nfs-utils

I have made an effort to make nfs-utils work with Heimdal.  Love has
made an effort to support functions we need in order to get "legal"
access to context information.

I have tested nfs-utils with recent release candidates of 0.8 which
provides the functions mentioned above to give us "legal" access to
context information which we need to pass down to the kernel.

In theory, any multi-mechanism libgssapi should work.  I haven't
actually tried to use Heimdal's version directly.  The MIT version
currently does not support the use of mechanisms not built within
their source tree.  (Dynamically loading external mechanisms is not
supported.)  We need this support to use our SPKM3 mechanism.  Our
libgssapi can use the heimdal libgssapi as one of the mechanisms that
we load.  (In hindsight, perhaps we should have named our libgssapi

When Heimdal 0.8 is released, nfs-utils should work with it.  If not,
I'll put more effort into making it work.


On 2/27/07, Martin von Gagern <Martin.vGagern@gmx.net> wrote:
> Hash: SHA1
> Hello!
> I'm trying to explore how to get nfs-utils working on Gentoo with
> heimdal. I encountered several issues along the way.
> 1. setup supported?
> Should this in principle be possible? Do heimdal and nfs-utils in theory
> support each other? Or is the heimdal code in nfs-utils just for ongoing
> development and not (yet) expected to work?
> 2. libgssapi.so?
> nfs-utils (both 1.0.10 and 1.0.12) requires librpcsecgss [1], which in
> turn depends on a libgssapi. But there are two implementations of this.
> One libgssapi.so is installed bei heimdal [2], the other comes from the
> libgssapi-0.10 package from CITI [3].
> Having them both installed at the same time seems to be at least not
> straightforward. But what's the solution?
> Is there some tweak to have them installed at the same time?
> Will libgssapi be a wrapper around the heimdal library?
> Or is the heimdal library instead a replacement for libgssapi?
> In that case it would require a pkgconfig description to allow the
> librpcsecgss script to find it.
> 3. gss_ctx_id_t?
> Both packages, heimdal and the CITI libgssapi, provide a gssapi.h that
> defines gss_ctx_id_t as a pointer. In heimdal it is a pointer to an
> incomplete type, in libgssapi it is a void pointer. However, the
> context_heimdal.c from nfs-utils dereferences pointers of this kind
> several times. There is a comment that says to use the gssapi.h from
> heimdal. And the heimdal ChangeLog says that gss_ctx_id_t_desc_struct,
> of which gss_ctx_id_t is a pointer, should not be exported [4].
> I could find very little information on this whole subject on the net.
> Maybe I'm doing something completely wrong, or maybe Gentoo does
> something weird in a location where I haven't noticed it, but for all I
> know this issue should be reproducible when compiling everything from
> sources and simply letting configure do its stuff.
> I'm more toying with this package, and have no immediate need to get
> this working. Still I'd like to see this resolved, so I'll appreciate
> any help as to how this could be done.
> Notice that I'm writing to both heimdal and nfs lists, as I'm not sure
> where the problem actually lies. You might wish to have a look at the
> archive of the other list as well to look for replies there.
> Greetings,
>  Martin von Gagern
> [1] http://www.citi.umich.edu/projects/nfsv4/linux/librpcsecgss/
> [2] ftp://ftp.pdc.kth.se/pub/heimdal/src/
> [3] http://www.citi.umich.edu/projects/nfsv4/linux/libgssapi/
> [4] http://bugs.gentoo.org/show_bug.cgi?id=134064#c7
> Version: GnuPG v2.0.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQFF5L1LRhp6o4m9dFsRAi6PAJ0Y59csO/ToDyNi+Wq43lmakTTMbwCglsuG
> LT8/Lo9YNTGJL8FowcTgqbU=
> =1Idy
> _______________________________________________
> NFSv4 mailing list
> NFSv4@linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4