[LU-3490] GSSAPI support not tested by Gerritt

• Type: Technical task
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.5.0
• Affects Version/s: Lustre 2.4.1
• Labels: SSK patch
• Environment: All
• Assignee: Minh Diep
• Reporter: Andrew Korty (Inactive)

Issue Links

• is related to: LU-3288 Enabling GSSAPI support requires Kerberos libraries to be installed

Comments

[Patrick Farrell (Inactive)]

Thomas,

Definitely, that patch would give that error. If you look in Gerrit, that commit is patch set 4, and we're on to patch set 6.

It actually appears that function is no longer being used, because we removed rc entirely and patch set 6 built successfully on all platforms. ('rc' was put there in patch set 4 to avoid a warning about ignoring a return value on write, but then hits the error you noted.)

[Thomas Stibor]

Hello,

I just discovered a problem with the commit 67b73336d5b3d631e6d9eb3809914b8b80825a24:

diff --git a/lustre/utils/gss/svcgssd.c b/lustre/utils/gss/svcgssd.c
index cebd852..bd6a4de 100644
--- a/lustre/utils/gss/svcgssd.c
+++ b/lustre/utils/gss/svcgssd.c
@@ -148,10 +148,10 @@ mydaemon(int nochdir, int noclose)
 static void
 release_parent()
 {
-       int status;
+       int status, rc;
 
        if (pipefds[1] > 0) {
-               write(pipefds[1], &status, 1);
+               rc = write(pipefds[1], &status, 1);
                close(pipefds[1]);
                pipefds[1] = -1;
        }

Since the code is compiled with gcc -Werror ... it results in:

svcgssd.c: In function ‘release_parent’:
svcgssd.c:151:14: error: variable ‘rc’ set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make[1]: *** [lsvcgssd-svcgssd.o] Error 1

[Thomas Stibor]

The function name krb5_derive_key was renamed in MIT-Kerberos >= 1.8.X.

Before it was (<= 1.7.X):

thomas@lxdv65:~/tmp/krb/krb5-1.7.2>grep -r "krb5int_derive_key"
thomas@lxdv65:~/tmp/krb/krb5-1.7.2>grep -r "krb5_derive_key"   
src/lib/crypto/vectors.c:    r = krb5_derive_key (enc, in, out, usage);
src/lib/crypto/combine_keys.c: * DK is defined as the key derivation function (krb5_derive_key())
src/lib/crypto/combine_keys.c:    if ((ret = krb5_derive_key(enc, &tkey, outkey, &input))) {
src/lib/crypto/aes/aes_s2k.c:    err = krb5_derive_key (enc, key, key, &usage);
src/lib/crypto/libk5crypto.exports:krb5_derive_key
src/lib/crypto/dk/dk_encrypt.c:    if ((ret = krb5_derive_key(enc, key, &ke, &d1)))
...

With version >= 1.8.X it changed to:

thomas@lxdv65:~/tmp/krb/krb5-1.8.6>grep -r "krb5_derive_key"
doc/CHANGES:Rename some lingering krb5_derive_key references.
thomas@lxdv65:~/tmp/krb/krb5-1.8.6>grep -r "krb5int_derive_key"
README:6629    krb5int_derive_key results in cache with uninitialized values
doc/CHANGES: subject: krb5int_derive_key results in cache with uninitialized values
doc/CHANGES: krb5int_derive_key creates a temporary keyblock to add to the derived cache.
src/lib/crypto/crypto_tests/vectors.c:    r = krb5int_derive_key (enc, in, out, usage);
src/lib/crypto/krb/combine_keys.c: * DK is defined as the key derivation function (krb5int_derive_key())
src/lib/crypto/krb/combine_keys.c:    ret = krb5int_derive_keyblock(enc, tkey, outkey, &input);
...

The newer distributions usually ship MIT-Kerberos => 1.8.X, however I haven't looked into Heimdal. There it is probably different.

[Minh Diep]

I'd say if we can't fine both krb5int_derive_key and krb5_derive_key, we will issue a warning and set HAVE_KRB5 to 0

[Patrick Farrell (Inactive)]

Minh,

I see if we have krb5int_derive_key, it will build correctly, because it's used instead of krb5_derive_key.

But some platforms have krb5_derive_key, and in that case, they don't need krb5int_derive_key in the libraries.

Is it possible that krb5int_derive_key is in one of the two possible GSS libraries and not the other? Maybe we need to require that library if you don't have krb5_derive_key in your kernel? (The SLES11SP1 case.)

Andreas,

It seems to me the problem with ignoring SLES11 because it's not supported going forward is that GSS_KEYRING won't build with at least b2_4 and possibly earlier versions as well. If it's supported there but can't actually be built...

[Minh Diep]

Patrick, Ken

Do you think 'checking for krb5int_derive_key in -lgssapi_krb5... no' must be yes to be able to build krb?

[Andreas Dilger]

I don't think we are supporting SLES11 SP1 going forward on master, so this may be a non-issue. We need to change out builders to take this into account.

[Patrick Farrell (Inactive)]

Here's the specific failure for SLES11SP1:
cc1: warnings being treated as errors
context_lucid.c: In function 'derive_key_lucid':
context_lucid.c:354: error: call to function 'krb5_derive_key' without a real prototype
context.h:46: note: 'krb5_derive_key' was declared here

A bit of looking at the source for SLES11SP2 and CentOS vs SLES11SP1 shows that function is defined in SLES11SP2 and CentOS, but it's not found in SLES11SP1.
It looks like the patch here which put functionality for deriving kerberos keys in to the kernel isn't in SLES11SP1.
That patch is here:
http://www.mail-archive.com/[e-mail]/msg01668.html

So I don't think there's an easy solution here if we actually want this to work on SLES11SP1, especially not if it's supposed to work on patchless clients.

—

Ken,

It looks like you're right. Still, that function is found in lgssglue in SLES11SP1 and CentOS, so we're OK there.

[Ken Hornstein]

Some versions of the GSS library don't provide gss_export_lucid_sec_context(), depending on the vintage. I'm actually in that situation, for a long, complicated, and stupid reason.

I suspect that -lgssapi (typically provided by a Kerberos implementation) shipped with SLES11SP1 is one of those vintages.

[Patrick Farrell (Inactive)]

Minh,

Not in general. This is the output for el6 inkernel from the same build (http://build.whamcloud.com/job/lustre-reviews/18238/arch=x86_64,build_type=server,distro=el6,ib_stack=inkernel/consoleFull):
checking for gss_export_lucid_sec_context in -lgssapi... no
checking for gss_export_lucid_sec_context in -lgssglue... yes

So that same situation works for el6.
One of lgssapi or lgssglue seems to be sufficient.

Maybe that's not true for sles11sp1.

[Minh Diep]

The reason it failed in sles11sp1 but not sles11sp2 is

sles11sp1:
checking for gss_export_lucid_sec_context in -lgssapi... no
checking for gss_export_lucid_sec_context in -lgssglue... yes <<<<

sles11sp2:
checking for gss_export_lucid_sec_context in -lgssapi... no
checking for gss_export_lucid_sec_context in -lgssglue... no

I believe the logic in the patch

AC_CHECK_LIB([gssapi], [gss_export_lucid_sec_context],
[GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssapi";
gss_conf_test='success'],
[AC_CHECK_LIB([gssglue], [gss_export_lucid_sec_context],
[GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssglue";
gss_conf_test='success'],
[if test x$enable_gss == xyes; then
AC_MSG_ERROR([libgssapi or libgssglue is not found, which is required by GSS.])
else
AC_MSG_WARN([libgssapi or libgssglue is not found, which is required by GSS.])
fi])],)

do we need both libgssapi and libgssglue to be yes or both to be no?