Libgssglue is not really useful anymore, it is a sort of middleman that
wraps the actual GSSAPI that is already pluggable/extensible via shared
modules.
In particular libgssglue interferes with the workings of gss-proxy in my
case.
The attached patch makes building against libgssglue optional and
defaults to not build against libgssglue and instead builds directly
against the native GSSAPI.
./configure --enable-gss
will now build against GSSAPI
./configure --enable-gss --with-gssglue
will keep building against libgssglue in case someone still needs it for
whatever reason.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Simo Sorce <simo@...> writes:
>
> Libgssglue is not really useful anymore, it is a sort of middleman that
> wraps the actual GSSAPI that is already pluggable/extensible via shared
> modules.
>
> In particular libgssglue interferes with the workings of gss-proxy in my
> case.
>
> The attached patch makes building against libgssglue optional and
> defaults to not build against libgssglue and instead builds directly
> against the native GSSAPI.
>
I have tried your patch with my Heimdal setup and it would not build properly
with it.
I can augment my patch to make use of your changes. Would you be willing to
consider it?
On 26/03/13 13:00, Simo Sorce wrote:
> Libgssglue is not really useful anymore, it is a sort of middleman that
> wraps the actual GSSAPI that is already pluggable/extensible via shared
> modules.
>
> In particular libgssglue interferes with the workings of gss-proxy in my
> case.
>
> The attached patch makes building against libgssglue optional and
> defaults to not build against libgssglue and instead builds directly
> against the native GSSAPI.
>
> ./configure --enable-gss
> will now build against GSSAPI
>
> ./configure --enable-gss --with-gssglue
> will keep building against libgssglue in case someone still needs it for
> whatever reason.
Committed...
steved.
Hi,
>>?
>> I can augment my patch to make use of your changes. Would you be willing to
>> consider it?
> I when ahead and took Simo's patches but I would like to continue to work
> with on get your Heimdal build working again... What exactly broke?
>
I thought you were CCed of follow up messages as well.
Basically, Simo's patches fix most of the problems with building on Heimdal
(these problems came?from libgssglue direction). Only 3 problems remained, which
I addressed in the follow-up patch:
> 1. On some systems, only libroken.so is available (small fix to kerberos5.m4)
>?
> 2. krb5_util.c:check_for_target - Heimdal variant constructs a "pattern"
>? ? principal and uses krb5_cc_retrieve_cred to get a matching credential.
>? ? This should work on mit-krb5, so old method of iterating over every
>? ? credential in cache may possibly be dropped outright and "#$if" guard
>? ? omitted.
>? ? For the sake of the above I reformatted the old approach to make it a bit
>? ? more clear what's going on there.
>?
> 3. krb5_util.c:gssd_k5_err_msg - krb5_get_err_text is marked as deprecated,
>? ? at least on Heimdal. If krb5_get_error_message is available, it should not
>? ? be reached at all, thus "#elif" guard.
Per issue 2, Simo told me he's going to look at it himself, with a view to remove
"#if" branching altogether (present code at that location is mit-krb5 implementation
specific).
Issue 3 is somewhat not clear to me: should krb5_get_err_text stay at all?
It's deprecated on Heimdal and apparently is not supported on mit-krb5 at all.
Which other kerberos libraries may need to be supported by the code?
On Tue, 2013-04-02 at 13:57 -0400, Steve Dickson wrote:
> Again using git send-email to post your patches would make this
> a lot easier... ;-)
Will do from here on.
> On 26/03/13 13:00, Simo Sorce wrote:
> > Libgssglue is not really useful anymore, it is a sort of middleman that
> > wraps the actual GSSAPI that is already pluggable/extensible via shared
> > modules.
> >
> > In particular libgssglue interferes with the workings of gss-proxy in my
> > case.
> >
> > The attached patch makes building against libgssglue optional and
> > defaults to not build against libgssglue and instead builds directly
> > against the native GSSAPI.
> >
> > ./configure --enable-gss
> > will now build against GSSAPI
> >
> > ./configure --enable-gss --with-gssglue
> > will keep building against libgssglue in case someone still needs it for
> > whatever reason.
> >
> in he first patch you define HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT
> which is good:
>
> --- a/aclocal/kerberos5.m4
> +++ b/aclocal/kerberos5.m4
> @@ -92,6 +92,8 @@ AC_DEFUN([AC_KERBEROS_V5],[
> AC_DEFINE(HAVE_SET_ALLOWABLE_ENCTYPES, 1, [Define this if the Kerberos GSS library supports gss_krb5_set_allowable_enctypes]), ,$KRBLIBS)
> AC_CHECK_LIB($gssapi_lib, gss_krb5_ccache_name,
> AC_DEFINE(HAVE_GSS_KRB5_CCACHE_NAME, 1, [Define this if the Kerberos GSS library supports gss_krb5_ccache_name]), ,$KRBLIBS)
> + AC_CHECK_LIB($gssapi_lib, gss_krb5_free_lucid_sec_context,
> + AC_DEFINE(HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT, 1, [Define this if the Kerberos GSS library supports gss_krb5_free_lucid_sec_context]), ,$KRBLIBS)
>
> dnl Check for newer error message facility
> AC_CHECK_LIB($gssapi_lib, krb5_get_error_message,
>
> But in the second patch you use a non-existent define HAVE_LIBGSSGLUE.
> Why not just use HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT?
Because the mere fact the native GSSAPI library have that function is
not the decisive factor we use to determine against what we want to
compile.
It's true that after I reordered patches the definition of
HAVE_LIBGSSGLUE ended up in the 3rd patch, but that is a venial problem
I hope.
> --- a/utils/gssd/gss_util.h
> +++ b/utils/gssd/gss_util.h
> @@ -42,4 +42,14 @@ void pgsserr(char *msg, u_int32_t maj_stat, u_int32_t min_stat,
> const gss_OID mech);
> int gssd_check_mechs(void);
>
> +#ifndef HAVE_LIBGSSGLUE
> +#include <gssapi/gssapi_krb5.h>
> +#define gss_free_lucid_sec_context(min, ctx, ret) \
> + gss_krb5_free_lucid_sec_context(min, ret)
> +
> +#define gss_export_lucid_sec_context gss_krb5_export_lucid_sec_context
> +#define gss_set_allowable_enctypes(min, cred, oid, num, types) \
> + gss_krb5_set_allowable_enctypes(min, cred, num, types)
> +#endif
> +
> Personally I like the way Alex handled this in his patch better..
The way Alex handled it makes it impossible to build against libgssglue,
and I have not removed libgssglue just made it optional.
This way is not pretty but allows to still compile against libgssglue if
needed.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
On 27/03/13 10:43, Alex Dubov wrote:
> Simo Sorce <simo@...> writes:
>
>>
>> Libgssglue is not really useful anymore, it is a sort of middleman that
>> wraps the actual GSSAPI that is already pluggable/extensible via shared
>> modules.
>>
>> In particular libgssglue interferes with the workings of gss-proxy in my
>> case.
>>
>> The attached patch makes building against libgssglue optional and
>> defaults to not build against libgssglue and instead builds directly
>> against the native GSSAPI.
>>
>
> I have tried your patch with my Heimdal setup and it would not build properly
> with it.
>
> I can augment my patch to make use of your changes. Would you be willing to
> consider it?
I when ahead and took Simo's patches but I would like to continue to work
with on get your Heimdal build working again... What exactly broke?
steved.
Again using git send-email to post your patches would make this
a lot easier... ;-)
On 26/03/13 13:00, Simo Sorce wrote:
> Libgssglue is not really useful anymore, it is a sort of middleman that
> wraps the actual GSSAPI that is already pluggable/extensible via shared
> modules.
>
> In particular libgssglue interferes with the workings of gss-proxy in my
> case.
>
> The attached patch makes building against libgssglue optional and
> defaults to not build against libgssglue and instead builds directly
> against the native GSSAPI.
>
> ./configure --enable-gss
> will now build against GSSAPI
>
> ./configure --enable-gss --with-gssglue
> will keep building against libgssglue in case someone still needs it for
> whatever reason.
>
in he first patch you define HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT
which is good:
--- a/aclocal/kerberos5.m4
+++ b/aclocal/kerberos5.m4
@@ -92,6 +92,8 @@ AC_DEFUN([AC_KERBEROS_V5],[
AC_DEFINE(HAVE_SET_ALLOWABLE_ENCTYPES, 1, [Define this if the Kerberos GSS library supports gss_krb5_set_allowable_enctypes]), ,$KRBLIBS)
AC_CHECK_LIB($gssapi_lib, gss_krb5_ccache_name,
AC_DEFINE(HAVE_GSS_KRB5_CCACHE_NAME, 1, [Define this if the Kerberos GSS library supports gss_krb5_ccache_name]), ,$KRBLIBS)
+ AC_CHECK_LIB($gssapi_lib, gss_krb5_free_lucid_sec_context,
+ AC_DEFINE(HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT, 1, [Define this if the Kerberos GSS library supports gss_krb5_free_lucid_sec_context]), ,$KRBLIBS)
dnl Check for newer error message facility
AC_CHECK_LIB($gssapi_lib, krb5_get_error_message,
But in the second patch you use a non-existent define HAVE_LIBGSSGLUE.
Why not just use HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT?
--- a/utils/gssd/gss_util.h
+++ b/utils/gssd/gss_util.h
@@ -42,4 +42,14 @@ void pgsserr(char *msg, u_int32_t maj_stat, u_int32_t min_stat,
const gss_OID mech);
int gssd_check_mechs(void);
+#ifndef HAVE_LIBGSSGLUE
+#include <gssapi/gssapi_krb5.h>
+#define gss_free_lucid_sec_context(min, ctx, ret) \
+ gss_krb5_free_lucid_sec_context(min, ret)
+
+#define gss_export_lucid_sec_context gss_krb5_export_lucid_sec_context
+#define gss_set_allowable_enctypes(min, cred, oid, num, types) \
+ gss_krb5_set_allowable_enctypes(min, cred, num, types)
+#endif
+
Personally I like the way Alex handled this in his patch better..
steved.
CC-ing Simo since he is not on this mailing list...
On 27/03/13 10:43, Alex Dubov wrote:
> Simo Sorce <simo@...> writes:
>
>>
>> Libgssglue is not really useful anymore, it is a sort of middleman that
>> wraps the actual GSSAPI that is already pluggable/extensible via shared
>> modules.
>>
>> In particular libgssglue interferes with the workings of gss-proxy in my
>> case.
>>
>> The attached patch makes building against libgssglue optional and
>> defaults to not build against libgssglue and instead builds directly
>> against the native GSSAPI.
>>
>
> I have tried your patch with my Heimdal setup and it would not build properly
> with it.
>
> I can augment my patch to make use of your changes. Would you be willing to
> consider it?
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>