From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 07:30:10 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 320561065672; Mon, 5 Oct 2009 07:30:10 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id AAFC68FC08; Mon, 5 Oct 2009 07:30:09 +0000 (UTC) Received: from [IPv6:2001:470:909f:1:225:ff:feed:9426] (unknown [IPv6:2001:470:909f:1:225:ff:feed:9426]) by itchy.rabson.org (Postfix) with ESMTP id EEA1D5C2F; Mon, 5 Oct 2009 08:29:37 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Doug Rabson In-Reply-To: <54ee35ff63fa25ea4c082134892835fb@mail> Date: Mon, 5 Oct 2009 08:29:37 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0EA2E119-29DF-4DDE-84C3-432E35D61C76@rabson.org> References: <54ee35ff63fa25ea4c082134892835fb@mail> To: Alexander Nedotsukov X-Mailer: Apple Mail (2.1076) Cc: Doug Rabson , Rick Macklem , John Baldwin , freebsd-current@FreeBSD.org, John Marshall , George Mamalakis Subject: Re: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 07:30:10 -0000 This is the core of the problem, I think. There are two possible solutions: 1. Link libgssapi_foo.so against libgssapi.so. I'm not a fan of this because it will encourage people to link with libgssapi_krb5.so when they really ought to be linking with libgssapi.so to give them mechanism independance. 2. Split the various mechanism libs in to two parts, mech_foo.so which will contain the actual mechanism implementation (this can link with libgssapi.so to handle the RTLD_LOCAL issue) and optionally libgssapi_foo.so to contain any mechanism-specific extensions. Clearly (2) is unsuitable for 8.0 but could happen in current. I guess we could use (1) as a band-aid fix for 8.0. On 5 Oct 2009, at 05:50, Alexander Nedotsukov wrote: > > Actually this may mean quite otherwise. > What I saying is if some code (eg. libsasl) dlopen() libgssapi as > RTLD_LOCAL then later attempt to load libgssapi_xxx inside libgssapi > may > fail because of this: > > $ldd /usr/lib/libgssapi_spnego.so > /usr/lib/libgssapi_spnego.so: > libasn1.so.10 => /usr/lib/libasn1.so.10 (0x28300000) > libc.so.7 => /lib/libc.so.7 (0x2808f000) > > I would expect to see libgssapi.so.10 dependency here. > > On Mon, 5 Oct 2009 10:07:20 +1100, John Marshall > wrote: >> On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >>> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >>>> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >>>>> On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >>>>> >> [snip] >>>>>> >>>>>> Now, hopefully someone who understands enough about dynamic >>>>>> linking will >>>>>> know if this is the correct fix for 8.0? (I'm going on a couple > of >>>>>> weeks >>>>>> vacation at the end of this week, so I won't be around to commit >>>>>> anything >>>>>> and don't understand it well enough to know if this is the > correct >>>>>> way >>>>>> to fix it.) >>>>>> >>>>>> So, hopefully someone else can pick this one up? >>>>>> >> [snip] >>>>> >>>>> I have submitted a patch to the FreeBSD Makefile which patches the >>>>> vendor-supplied template for krb5-config. I should be grateful if >>>>> dfr@ >>>>> or another src committer would please review this with a view to >>>>> obtaining re@ approval to commit it before 8.0-RC2. >>>>> >>>>> >>>> >>>> Any src committers able to help with this? >>> >>> Hmmm, I thought that libgssapi was supposed to use dlopen to load >>> the >>> proper >>> back-end libraries using /etc/gss/mech rather than having >>> applications >>> directly link against them. >> >> OK, so if my proposed solution is, in fact, only masking a symptom >> of a >> broken dynamic linker, would somebody who understands this stuff >> please >> weigh in on this with some debugging suggestions or with a patch to >> address this problem? >> >> I'm able to help with testing but I'm not a programmer and know >> nothing >> about the FreeBSD dynamic linker. >> >> Thanks.