[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

[Peter Jones]

Landed for 2.5.0

[Andreas Dilger]

Making this a blocker for 2.5.0 until the configure/build problem is fixed for systems that do not have the gss libraries installed.

[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.