Created attachment 957636 [details]
proposed patch

I can confirm that the patch solves the issue with pkinit.so form krb5-1.11 package. After applying it the test stop failing and the pkinit.so from the installed package is not loaded.

However, I see that libraries from the installed krb5-libs are still used. Although, this not causes any test failure, IMO the libraries from build should be used. Is my assumption correct? Should we maybe open a new case for this?


Here is what I see:

# for i in `rpm -ql krb5-libs | grep so`; do auditctl -w $i -p warx -k KRB5_LIBS; done
# pwd
/root/rpmbuild/BUILD/krb5-1.12.2/src/lib/kadm5/unit-test
# make check
... snip ...
# echo $?
0
#
# ausearch -i -k KRB5_LIBS
----
type=PATH msg=audit(11/14/2014 11:16:04.131:375149) : item=0 name=/lib64/libkadm5srv_mit.so.8 inode=76534412 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:lib_t:s0 objtype=NORMAL 
type=CWD msg=audit(11/14/2014 11:16:04.131:375149) :  cwd=/root/rpmbuild/BUILD/krb5-1.12.2/src/lib/kadm5/unit-test 
type=SYSCALL msg=audit(11/14/2014 11:16:04.131:375149) : arch=ppc64 syscall=open success=yes exit=3 a0=0x3fffa7ae0bb2 a1=O_RDONLY|O_CLOEXEC a2=0x10021d44740 a3=0x8 items=1 ppid=53254 pid=53260 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=92 comm=kdb5_util exe=/root/rpmbuild/BUILD/krb5-1.12.2/src/kadmin/dbutil/kdb5_util subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=KRB5_LIBS 
----
type=PATH msg=audit(11/14/2014 11:16:04.241:375150) : item=0 name=/usr/lib64/krb5/plugins/kdb/db2.so inode=100665753 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:lib_t:s0 objtype=NORMAL 
type=CWD msg=audit(11/14/2014 11:16:04.241:375150) :  cwd=/root/rpmbuild/BUILD/krb5-1.12.2/src/lib/kadm5/unit-test 
type=SYSCALL msg=audit(11/14/2014 11:16:04.241:375150) : arch=ppc64 syscall=open success=yes exit=4 a0=0x10021d8d470 a1=O_RDONLY|O_CLOEXEC a2=0x3fffa83c5c50 a3=0x0 items=1 ppid=53254 pid=53260 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=92 comm=kdb5_util exe=/root/rpmbuild/BUILD/krb5-1.12.2/src/kadmin/dbutil/kdb5_util subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=KRB5_LIBS 
----
type=PATH msg=audit(11/14/2014 11:16:04.241:375151) : item=0 name=/lib64/libkadm5srv_mit.so.8 inode=76534412 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:lib_t:s0 objtype=NORMAL 
type=CWD msg=audit(11/14/2014 11:16:04.241:375151) :  cwd=/root/rpmbuild/BUILD/krb5-1.12.2/src/lib/kadm5/unit-test 
type=SYSCALL msg=audit(11/14/2014 11:16:04.241:375151) : arch=ppc64 syscall=open success=yes exit=4 a0=0x3fffa7990bb2 a1=O_RDONLY|O_CLOEXEC a2=0x10021d8d4a0 a3=0x8 items=1 ppid=53254 pid=53260 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=92 comm=kdb5_util exe=/root/rpmbuild/BUILD/krb5-1.12.2/src/kadmin/dbutil/kdb5_util subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=KRB5_LIBS 
----

... and many more such a logs ...

Just a short summary about the consequences of this issue.

This problem causing that upstream tests are loading libs from the installed packages instead of the built (tested) ones so the tests are not really testing the release that they suppose to. This is the case especially on automated test/build systems which have older version of krb5 installed than what is actually built/tested.
There is an easy workaround, though (build the new package, install it, and run again the tests), but the issue make troubles on automated systems.

Fixed in krb5-1.13.2-2.el7 (and Fedora krb5-1.13.2-1.fc23 and krb5-1.13.2-1.fc22) ...

... marking bug as MODIFIED.

Opened pull request upstream.

Regarding comment 2: the krb5 test suite uses the profile variable db_module_dirs to cause KDB modules to be loaded from the build tree instead of the install tree.  The semantics of that variable are kind of dumb: the specified values *and* the install tree location are concatenated together in order, all matching shared objects from those directories are loaded, and then only the first object (which should be the one from the build tree) is actually used.

So, we aren't actually using the db2.so from the install tree, but we are loading it, which looks alarming.  This and a few other problems should get cleaned up, but there's no issue with us testing the wrong code during "make check".

(In reply to Greg Hudson from comment #11)
> Regarding comment 2: the krb5 test suite uses the profile variable
> db_module_dirs to cause KDB modules to be loaded from the build tree instead
> of the install tree.  The semantics of that variable are kind of dumb: the
> specified values *and* the install tree location are concatenated together
> in order, all matching shared objects from those directories are loaded, and
> then only the first object (which should be the one from the build tree) is
> actually used.
> 
> So, we aren't actually using the db2.so from the install tree, but we are
> loading it, which looks alarming.  This and a few other problems should get
> cleaned up, but there's no issue with us testing the wrong code during "make
> check".

Thanks Greg for the explanation.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2154.html