Red Hat Bugzilla – Bug 720479
nfs-utils-1.2.3 breaks svcgssd - incorrectly orders libraries when built from source
Last modified: 2013-10-18 02:07:53 EDT
Description of problem: Building nfs-utils-1.2.3 from nfs-utils-1.2.3-7.el6.src results in a non-functional svcgssd due to incorrect library order at link time. Libgssapi_krb5 duplicates symbols in libgssglue, but svcgssd fails to function properly when running through libgssapi_krb5. This is due to libtool looking up dependencies in libtirpc.la, of which lgssglue is one, and moving them to the end of the list. Libtool is designed to do this, and contains notes explaining that behavior. Configured with ./configure Version-Release number of selected component (if applicable): libtirpc-devel-0.2.1-3.el6.x86_64 libtool-2.2.6-15.5.el6.x86_64 Steps to Reproduce: [root@kudu1 gssd]# make /bin/sh ../../libtool --tag=CC --mode=link gcc -Wall -Wextra -Wstrict-prototypes -pipe -g -O2 -I/usr/include/gssglue -g -O2 -o svcgssd svcgssd-context.o svcgssd-context_mit.o svcgssd-context_heimdal.o svcgssd-context_lucid.o svcgssd-context_spkm3.o svcgssd-gss_util.o svcgssd-gss_oids.o svcgssd-err_util.o svcgssd-svcgssd.o svcgssd-svcgssd_main_loop.o svcgssd-svcgssd_mech2file.o svcgssd-svcgssd_proc.o ../../support/nfs/libnfs.a -lgssglue -ldl -lnfsidmap -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ltirpc libtool: link: warning: library `/lib64/libtirpc.la' was moved. libtool: link: warning: library `/lib64/libtirpc.la' was moved. libtool: link: gcc -Wall -Wextra -Wstrict-prototypes -pipe -g -O2 -I/usr/include/gssglue -g -O2 -o svcgssd svcgssd-context.o svcgssd-context_mit.o svcgssd-context_heimdal.o svcgssd-context_lucid.o svcgssd-context_spkm3.o svcgssd-gss_util.o svcgssd-gss_oids.o svcgssd-err_util.o svcgssd-svcgssd.o svcgssd-svcgssd_main_loop.o svcgssd-svcgssd_mech2file.o svcgssd-svcgssd_proc.o ../../support/nfs/libnfs.a /usr/lib64/libnfsidmap.so -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err /lib64/libtirpc.so -lnsl -lgssglue -ldl -lpthread Actual results: svcgssd[15145]: DEBUG: serialize_krb5_ctx: lucid version! svcgssd[15145]: ERROR: GSS-API: error in gss_export_lucid_sec_context(): GSS_S_NO_CONTEXT (No context has been established) - (0x00007fff) svcgssd[15145]: ERROR: failed serializing krb5 context for kernel svcgssd[15145]: WARNING: handle_nullreq: serialize_context_for_kernel failed Expected results: svcgssd[15820]: DEBUG: serialize_krb5_ctx: lucid version! svcgssd[15820]: prepare_krb5_rfc4121_buffer: protocol 0 svcgssd[15820]: prepare_krb5_rfc4121_buffer: serializing key with enctype 6 and size 24 svcgssd[15820]: doing downcall Additional info: A quick fix is to specify lgssglue as a linker option, which libtool ignores: GSSGLUE_CFLAGS="-Wl,-lgssglue" ./configure
Same problem here. The GSSGLUE quick fix works for me too.
*** Bug 727629 has been marked as a duplicate of this bug. ***
*** Bug 722616 has been marked as a duplicate of this bug. ***
verified on nfs-utils-1.2.3-8 and mount with secure is ok now. [root@ibm-himalaya cthon04]# rpm -qa|grep nfs-utils nfs-utils-1.2.3-8.el6.i686 nfs-utils-lib-1.1.5-4.el6.i686 [root@ibm-himalaya cthon04]# uname -a Linux ibm-himalaya.rhts.eng.bos.redhat.com 2.6.32-192.el6.i686 #1 SMP Tue Aug 23 14:34:49 EDT 2011 i686 i686 i386 GNU/Linux # rpc.svcgssd -fvvv handling null request sname = nfs/ibm-himalaya.rhts.eng.bos.redhat.com@RHTS.ENG.BOS.REDHAT.COM DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc4121_buffer: protocol 1 prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 doing downcall mech: krb5, hndl len: 4, ctx len 52, timeout: 1314847440 (86329 from now), clnt: nfs@ibm-himalaya.rhts.eng.bos.redhat.com, uid: -1, gid: -1, num aux grps: 0: sending null reply writing message: \x \x608202db06092a864886f71201020201006e8202ca308202c6a003020105a10302010ea20703050020000000a382019a6182019630820192a003020105a1191b17524854532e454e472e424f532e5245444841542e434f4da2363034a003020103a12d302b1b036e66731b247479616e2d677432342d30352e726874732e656e672e626f732e7265646861742e636f6da382013630820132a003020101a103020102a282012404820120074983194a575b4ac0e57656b4c37de85a4b7bfa85d1a9d38e78f821944c2a150849844bdc72a836121a8646a171728b8aeb06421b8098488da0d07ed4434827b3fcdc88a38646402095635afe4679a307d2489b8e39cb97120fcc7ce20b36ee3c468feb2c83e17433d829a2b3392d8478590a38a60d920748c586a69c3e3d59f556d5d338898bb9a07361081fa0ee5c4a5fa673c8ab4f0e42d53daed6466f2d6c1b2b05de494511781bca1de170544b2c708cfec6dbdfe69945bac8eb650453d8ab47446a7eedf7156ac389131cea475b48738dd9a921c60fef5fc496abed1a196073c674e06f0bd542ce2fe44e36ea84a62b63e8612988c4989a9ceb2aa6e6250cf6951979d5a1eaa783595997fe615972aea24358a1d5ad69978ede7c64faa48201113082010da003020101a282010404820100e70a3bfc1601162eecf8118c5a814bbe23d1ef372b54bd4d3275ec93d1544cd48d5773a2aaee5a1dbb1ab2ecfdc194ed2fd6fc378350dcdb43cf660bbd2447d783e7e8120b284309fa8dfa54242c51d0b11f1c4c39757817730892ecbe3bca368e745aacebe626cde2cc283d460ddc5613e55cbdceb955362edc69235cf4652e98f67f1f90c532fa9297a09a8826ba1c26939914c3d0c089472a6d530daff10631a156e47ae8189d4056065efff4852074013a23b1c85f2e32357e94f3f1ba06de136f4046b7b8406987c2919e4c0e9a8076510672a2f77341b21c1fd143c883f03dd118b9f406d6738467c4c359db49b3d5538be5065b28849c599fdca85f27 1314761171 0 0 \x02000000 \x60818806092a864886f71201020202006f793077a003020105a10302010fa26b3069a003020101a2620460ed479847720594c997ed95226afcd7b54f0d714b0db252eceed38f39985b34e92ab487106cacd07521396ae5b0239ac25d216368176de288ee11dad1531ef4b7ee327beb51363b39a8c299fe487f01420a9da9e77d12972c6d755ae5b0f61ef5 finished handling null request entering poll # rpc.gssd -fvvv dir_notify_handler: sig 37 si 0xbfba67dc data 0xbfba685c dir_notify_handler: sig 37 si 0xbfba1f3c data 0xbfba1fbc dir_notify_handler: sig 37 si 0xbfba672c data 0xbfba67ac handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt123) handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt123) process_krb5_upcall: service is '<null>' Full hostname for 'tyan-gt24-05.rhts.eng.bos.redhat.com' is 'tyan-gt24-05.rhts.eng.bos.redhat.com' Full hostname for 'ibm-himalaya.rhts.eng.bos.redhat.com' is 'ibm-himalaya.rhts.eng.bos.redhat.com' No key table entry found for IBM-HIMALAYA.RHTS.ENG.BOS.REDHAT.COM$@RHTS.ENG.BOS.REDHAT.COM while getting keytab entry for 'IBM-HIMALAYA.RHTS.ENG.BOS.REDHAT.COM$@RHTS.ENG.BOS.REDHAT.COM' No key table entry found for root/ibm-himalaya.rhts.eng.bos.redhat.com@RHTS.ENG.BOS.REDHAT.COM while getting keytab entry for 'root/ibm-himalaya.rhts.eng.bos.redhat.com@RHTS.ENG.BOS.REDHAT.COM' Success getting keytab entry for 'nfs/ibm-himalaya.rhts.eng.bos.redhat.com@RHTS.ENG.BOS.REDHAT.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_RHTS.ENG.BOS.REDHAT.COM' are good until 1314847440 INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_RHTS.ENG.BOS.REDHAT.COM' are good until 1314847440 using FILE:/tmp/krb5cc_machine_RHTS.ENG.BOS.REDHAT.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_RHTS.ENG.BOS.REDHAT.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server tyan-gt24-05.rhts.eng.bos.redhat.com DEBUG: port already set to 2049 creating context with server nfs@tyan-gt24-05.rhts.eng.bos.redhat.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc4121_buffer: protocol 1 prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 doing downcall dir_notify_handler: sig 37 si 0xbfba67dc data 0xbfba685c dir_notify_handler: sig 37 si 0xbfba67dc data 0xbfba685c dir_notify_handler: sig 37 si 0xbfba67dc data 0xbfba685c destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt124 # mount -t nfs -o sec=krb5 tyan-gt24-05.rhts.eng.bos.redhat.com:/nfs /mnt # cat /proc/mounts ... tyan-gt24-05.rhts.eng.bos.redhat.com:/nfs/ /mnt nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=10.16.64.245,minorversion=0,local_lock=none,addr=10.16.65.180 0 0
Will an update be pushed to RHEL 6.1 for this issue?
The status is currently VERIFIED. From the docs: VERIFIED This bug has been tested by QE, and passed the testing. From here, the bug will be moved to RELEASE_PENDING when the errata is moved to the HOLD state. RELEASE_PENDING The package in which this bug is contained has been approved by QE. From here, the most likely state is CLOSED(errata), which happens automatically when the errata goes out. However, the following two state transitions, athough rare, are also possible: ON_QA, if a problem and fix has been found, as well as ASSIGNED if a problem has been found, but no fix exists yet. You can find the errata here when it is released: https://rhn.redhat.com/errata/rhel-client-6-errata.html
Right, yes, understood. But my question was more "Is this going out as an update for 6.1, or being held for the 6.2 release?".
Any update on this?
*** Bug 712983 has been marked as a duplicate of this bug. ***
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. http://rhn.redhat.com/errata/RHSA-2011-1534.html
*** Bug 783208 has been marked as a duplicate of this bug. ***