Closed Bug 242029 Opened 20 years ago Closed 20 years ago

error trying to register libnegotiateauth.so

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta1

People

(Reporter: ajschult784, Assigned: darin.moz)

References

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: needed-aviary1.0?)

Attachments

(1 file)

v1 patch
1.45 KB, patch
bryner
: review+
asa
: approval-aviary+
mkaply
: approval1.7.5+
Details | Diff | Splinter Review 
With libnegotiateauth.so packaged with installer builds, I'm seeing the
following error running regxpcom:

nsNativeComponentLoader: SelfRegisterDll(libnegotiateauth.so) Load FAILED with
error: libcom_err.so.3: cannot open shared object file: No such file or directory

I have libcom_err.so.2, but not .3 on my system.  I have Fedora Core 1. 
Fedora-devel (and probably FC2) also ships with the older version of the library.

The message gets printed 3 times while running the installer, but it's not
printed when actually running Mozilla.
Summary: error trying to register libnegoiateauth.so → error trying to register libnegotiateauth.so
I'm seeing the exact same thing - I have .2 but not .3 on my Debian testing box.
this makes us look bad and we are apparently distributing an extension nobody
can use.
Flags: blocking1.8a?
ah.  libcom_err.so.3 is part of the krb5-libs-1.2.x package on older Red Hat
versions (how ridiculous).  But it's not part of the krb5-libs package for
Fedora Core 1 or Fedora devel (yay!).
-> Build Config

I'm presuming that fixing this bug is a matter of configuring the build systems
properly... whatever properly means.
Assignee: darin → nobody
Component: Networking → Build Config
QA Contact: benc → core.build-config
Is it time for the annual 'explicitly list external dependencies' vs running
'out of the box' debate?  The bug should be marked invalid unless we claim to
run 'out of the box' on every Linux distribution available, which I don't
believe we do.  Assuming that we're not talking about a static build here
(default seamonkey), linking against the static versions of the krb5 libs is out
of the question unless we want to revisit that 'linking non-PIC static libs into
a shared library' issue.

Btw, if anyone's wondering how Fedora managed to drop a major shared library
version on libcom_err, the krb5-libs package started using the version of
libcom_err that comes with e2fsprogs instead of bundling their own.  I don't
think it's possible for us to use the older version with the current version of
krb5 on the release machine.

> Is it time for the annual 'explicitly list external dependencies' vs running
> 'out of the box' debate?  The bug should be marked invalid unless we claim to
> run 'out of the box' on every Linux distribution available, which I don't
> believe we do.

If this can't work, fine.  If it does work, great.  I just don't think it's good
to have scary messages printed out every time people install a build.
(In reply to comment #5)
> The bug should be marked invalid unless we claim to
> run 'out of the box' on every Linux distribution available, 

This bug does not cause Mozilla not to run, right? It just makes negotiateauth
unavailable?
yes, Mozilla runs fine.
Same problem with Debian (Sid). Of course I tried the version of today (5.5.)
Blocks: 242795
*** Bug 242795 has been marked as a duplicate of this bug. ***
note that darin filed bug 243870 which would 'silence' the 'error'.

i'm a bit confused. is it impossible for our negotiate auth code to try 
dynamically loading symbols from libcom_err.so.2/libcom_err.so.3?
I didn't think the negotiate auth code used libcom_err directly.  I thought it
was a (explicit) shared library dependency from linking against -lkrb5.  
Besides that, what happens if somoene builds against a version of krb5 which
uses yet another version of libcom_err or they statically link against a special
version of those libs built with -fPIC?  I don't see the point of duplicating
the work of the dynamic loader to hide an additional library dependency.  We
should state the dependency explicitly. 
Just for information purposes, I get this same bug on SuSE 9.0 Porfessional and
on the latest SuSE 9.1 Porfessional.
Flags: blocking1.8a? → blocking1.8a-
With SuSE Linux 8.2 and Mozilla 1.7rc2 the error message appears for the .2 version:

nsNativeComponentLoader: SelfRegisterDll(libnegotiateauth.so) Load FAILED with
error: libgssapi_krb5.so.2: cannot open shared object file: No such file or
directory

bug 243870 seems to downplay this as an "insignificant error", but if it is, it
still has an effect: the application is not launched after installation.

In previous releases it always was, and I believe this was required.
On a Linux system, you normally install it as user root and should run it once,
and then of course you run it as a nonprivileged user.

Now, the run-as-root-once has to be done manually.
(not sure if these are related, maybe it isn't automatically started anyway)

Additional information.

SuSE 9.0 and 9.1 Professional use the heimdal-lib package for the kerberos
libraries.

rpm -q --info heimdal-lib

Name        : heimdal-lib                  Relocations: /usr
Version     : 0.6                               Vendor: SuSE Linux AG,
Nuernberg, Germany
Release     : 67                            Build Date: Tue 23 Sep 2003 04:32:24
PM EDT
Install date: Tue 17 Feb 2004 12:20:34 PM EST      Build Host: F12.suse.de
Group       : System/Libraries              Source RPM: heimdal-0.6-67.src.rpm
Size        : 916788                           License: BSD, Other License(s),
see package
Signature   : DSA/SHA1, Tue 23 Sep 2003 04:34:57 PM EDT, Key ID a84edae89c800aca
Packager    : http://www.suse.de/feedback
URL         : http://www.pdc.kth.se/heimdal/
Summary     : Free Kerberos5 implementation - libraries
Description :
Heimdal is a free implementation of Kerberos5 available from
http://www.pdc.kth.se/src/heimdal-devel, also the home of KTH-Krb -- a
free implementation of Kerberos4. Heimdal is maintained and produced in
Sweden (outside the US!), is in the public domain in the sense of the
Wassenaar agreement, and is freely exportable.



Authors:
--------
    heimdal@pdc.kth.se
Distribution: SuSE Linux 9.0 (i586)

> bug 243870 seems to downplay this as an "insignificant error", but if it is, it
> still has an effect: the application is not launched after installation.

this is by design and not related to the error.

> In previous releases it always was, and I believe this was required.
> On a Linux system, you normally install it as user root and should run it once,
> and then of course you run it as a nonprivileged user.

the installer now does what is necessary without actually running Mozilla by
running regxpcom and regchrome (bug 57089)
(In reply to comment #14)
> still has an effect: the application is not launched after installation.

No. This message can not be related to that.
*** Bug 247513 has been marked as a duplicate of this bug. ***
Blocks: 250014
(In reply to comment #5)
> Is it time for the annual 'explicitly list external dependencies' vs running
> 'out of the box' debate?  The bug should be marked invalid unless we claim to
> run 'out of the box' on every Linux distribution available, which I don't
> believe we do.

I would like to to know on which platforms/OS versions does negotiateauth work
out of the box?  Obviously we would like to reach the biggest community
possible, while not discouraging users from upgrading their kerberos libraries
to newer versions (there are often security sensitive fixes with every release).

Will negotiateauth continue to function if a user upgrades to the newest MIT
kerberos libraries? At least version 1.3.1 is needed for good compatibility with
Active Directory.

I'm going to send a note to the MIT kerberos mailing list and get their thoughts
on which version of MIT kerberos we should build on for greatest binary
compatiblity and AD Support.
Response from MIT kerberos list
http://diswww.mit.edu:8008/menelaus.mit.edu/kerberos/21944

It sounds like that if we upgraded and compiled against RedHat's 1.3x builds 
we would probably break compatiblity with every other linux distribution's MIT 
libraries (unless they followed suit and did the same thing, for whatever 
reason).

I'm thinking that it might make sense to dlopen the GSSAPI libraries instead of
linking to them at build time.  That might enable us to handle a greater variety
of GSSAPI installations.
Assignee: nobody → darin
Target Milestone: --- → mozilla1.8alpha2
Target Milestone: mozilla1.8alpha2 → mozilla1.8beta
bryner had a good idea.  why not only link to libgssapi_krb5.so?  it seems to
work on linux, as all of the symbols we use are contained in that library.  the
other libraries get loaded at runtime, but they are loaded based on what
libgssapi_krb5.so needs, not based on what our libnegotiateauth.so needs.
Status: NEW → ASSIGNED
(In reply to comment #22)
> bryner had a good idea.  why not only link to libgssapi_krb5.so?  it seems to
> work on linux, as all of the symbols we use are contained in that library.  the
> other libraries get loaded at runtime, but they are loaded based on what
> libgssapi_krb5.so needs, not based on what our libnegotiateauth.so needs.

I liked the dlopen idea in the long run because we could theoretically could get
compatiblity for every GSSAPI implementation in 1 build.  How close to this
could we get with just linking in the one library?
> I liked the dlopen idea in the long run because we could theoretically could get
> compatiblity for every GSSAPI implementation in 1 build.  How close to this
> could we get with just linking in the one library?

If we link just one library, then the name of that library matters.  It seems to
me that the library name varies depending on the gssapi implementation.  Using
dlopen, we could try to load several different libraries.

Optionally, we could also avoid #include'ing any gssapi headers.  But, do we
know for sure that every gssapi implementation exports the same base set of symbols?

What is the name of the gssapi library provided by heimdal?

As a quick fix for mozilla 1.7.2 and firefox 1.0, I'll probably just land the
change that bryner was suggesting.  I think Mozilla.org's main target should
probably be compatibility with different versions of MIT krb5 shipped by
supported versions of RedHat Linux and Mac OSX.
This is the list of files in heimdal. The gssapi lib names are libgssapi.so.1
and libgssapi.so.1.4.0. libgssapi.so.1 is a sym link to libgssapi.so.1.4.0.

$ rpm -ql heimdal-lib
/etc/krb5.conf
/usr/lib/libasn1.so.6
/usr/lib/libasn1.so.6.0.2
/usr/lib/libgssapi.so.1
/usr/lib/libgssapi.so.1.4.0
/usr/lib/libhdb.so.7
/usr/lib/libhdb.so.7.0.7
/usr/lib/libkadm5clnt.so.4
/usr/lib/libkadm5clnt.so.4.2.4
/usr/lib/libkadm5srv.so.7
/usr/lib/libkadm5srv.so.7.0.6
/usr/lib/libkafs.so.0
/usr/lib/libkafs.so.0.4.0
/usr/lib/libkrb5.so.17
/usr/lib/libkrb5.so.17.3.0
/usr/lib/libotp.so.0
/usr/lib/libotp.so.0.1.4
/usr/lib/libroken.so.16
/usr/lib/libroken.so.16.0.3
/usr/lib/libsl.so.0
/usr/lib/libsl.so.0.1.2
FWIW: I'm running Mandrake 10 and after installing negotiateauth and restarting
Mozilla I get:

nsNativeComponentLoader: SelfRegisterDll(libnegotiateauth.so) Load FAILED with
error: libstdc++.so.3: cannot open shared object file: No such file or directory

Versions used:
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7b) Gecko/20040316
libkrb51-1.3-6.2.100mdk
krb5-workstation-1.3-6.2.100mdk
libstdc++2.10-2.96-0.83mdk
libstdc++5-3.3.2-6mdk
libext2fs2-1.34-5mdk (supplies libcom_err.so)

(In reply to comment #26)
> FWIW: I'm running Mandrake 10 and after installing negotiateauth and restarting
> Mozilla I get:

What do you mean after installing negotiateauth?   It's standard in Mozilla 1.7
final (It may have been in the 1.7B but I don't think the parsing URL's worked
very well, so I wouldn't use it). Try just downloading 1.7 Final and at least
that problem should go away, but you might still have problems with libcommerr. 
I've installed 1.7 parallel to the 1.7b.
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7) Gecko/20040616
Is that Final?

None of them lists negotiateauth as a plug-in. Should it?

I installed negotiateauth from this site:
http://negotiateauth.mozdev.org/installation.html
(In reply to comment #28)
> I've installed 1.7 parallel to the 1.7b.
> Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7) Gecko/20040616
> Is that Final?

I think so.

> None of them lists negotiateauth as a plug-in. Should it?

No, its not a browser plugin its an extention so it won't be listed.  It will be
there by default.  To prove it do a find for libnegotiateauth.so in your Mozilla
1.7 install directory.   Also in 1.7 if it fails to load it will do it silently,
it will not give you an error message, it just won't work.

> I installed negotiateauth from this site:
> http://negotiateauth.mozdev.org/installation.html

There is no reason to use the installation files from that site anymore, all of
that code plus additional bug fixes is already included with Mozilla.

If you have additional problems post to Mozillazine forums or Mozilla-security
mailing list for support.  I will answer your questions from there, bugzilla
isn't the place for support questions.
Attached patch v1 patch — — Splinter Review 
Here's the simplest patch that makes us not link directly with libcom_err.so in
the MIT release.  This should solve the problem for system's with a version of
the MIT krb5 release that is newer than the one Mozilla was compiled against
(either the version that ships with RH7.x or RH8, depending on the Mozilla
Foundation build system that is used).
Attachment #153903 - Flags: review?(bryner)
Attachment #153903 - Flags: review?(bryner) → review+
Darin: I have tested this patch on AIX and it works fine.
Comment on attachment 153903 [details] [diff] [review]
v1 patch

this is a nice safe patch that would be good to have on the 1.7 branch
Attachment #153903 - Flags: approval1.7.2?
this is needed on the aviary 1.0 branch too.

fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Flags: blocking-aviary1.0RC1?
Resolution: --- → FIXED
Whiteboard: needed-aviary1.0?
Comment on attachment 153903 [details] [diff] [review]
v1 patch

a=mkaply
Attachment #153903 - Flags: approval1.7.2? → approval1.7.2+
fixed1.7.3
Keywords: fixed1.7.3
Comment on attachment 153903 [details] [diff] [review]
v1 patch

would be good to get this on the aviary 1.0 branch...
Attachment #153903 - Flags: approval-aviary?
Comment on attachment 153903 [details] [diff] [review]
v1 patch

a=asa for checkin to aviary.
Attachment #153903 - Flags: approval-aviary? → approval-aviary+
Keywords: fixed-aviary1.0
Flags: blocking-aviary1.0PR?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: