broken compatability between 1.3.5 and 1.4.1

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

broken compatability between 1.3.5 and 1.4.1

Paul Moore-3
Did you know this? The shared libraries are not binary compatible.
Certainly GSS applications built against the 1.3.5 libraries do not work
against 1.4.1 libs.
There is a missing symbol that the loader picks up in some cases.
a good example is openssh 3.9 built against 1.3.5. It segfaults against
1.4.1 when a gss connection comes into sshd
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: broken compatability between 1.3.5 and 1.4.1

Tom Yu
>>>>> "Paul" == Paul Moore <[hidden email]> writes:

Paul> Did you know this? The shared libraries are not binary compatible.
Paul> Certainly GSS applications built against the 1.3.5 libraries do not work
Paul> against 1.4.1 libs.
Paul> There is a missing symbol that the loader picks up in some cases.
Paul> a good example is openssh 3.9 built against 1.3.5. It segfaults against
Paul> 1.4.1 when a gss connection comes into sshd
 
Could you be specific about which symbols are missing, and on what
platform?

---Tom
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: broken compatability between 1.3.5 and 1.4.1

Tim Mooney
In reply to this post by Paul Moore-3
In regard to: broken compatability between 1.3.5 and 1.4.1, Paul Moore said...:

> Did you know this? The shared libraries are not binary compatible.
> Certainly GSS applications built against the 1.3.5 libraries do not work
> against 1.4.1 libs.
> There is a missing symbol that the loader picks up in some cases.
> a good example is openssh 3.9 built against 1.3.5. It segfaults against
> 1.4.1 when a gss connection comes into sshd

I reported this earlier too (February 10th), and it's bug # 2920 in
the MIT Kerberos bug database.

I'm glad you reported it; until now, it was looking like I was the only
person that had seen this.

Tim
--
Tim Mooney                              [hidden email]
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: broken compatability between 1.3.5 and 1.4.1

Tom Yu
>>>>> "Tim" == Tim Mooney <[hidden email]> writes:

Tim> In regard to: broken compatability between 1.3.5 and 1.4.1, Paul Moore said...:
>> Did you know this? The shared libraries are not binary compatible.
>> Certainly GSS applications built against the 1.3.5 libraries do not work
>> against 1.4.1 libs.
>> There is a missing symbol that the loader picks up in some cases.
>> a good example is openssh 3.9 built against 1.3.5. It segfaults against
>> 1.4.1 when a gss connection comes into sshd

Tim> I reported this earlier too (February 10th), and it's bug # 2920 in
Tim> the MIT Kerberos bug database.

Interesting.  As early as 1.2.x, the *_init_ets() functions were
marked as private, so prototypes should not have been available unless
KRB5_PRIVATE was defined.

Also, somewhere since 1.2.x, we started to use export lists to
restrict symbols exported from shared libraries on Unix platforms.

---Tom
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: broken compatability between 1.3.5 and 1.4.1

hartmans
In reply to this post by Tim Mooney
we committed to an ABI for Unix, Mac and windows around 1.2.5.

If you have an application using only symbols from that ABI (symbols
defined in our header files without KRB5_PRIVATE defined) we would
consider it a serious bug if such an application failed to link
against 1.4.1 libraries when built against 1.3.5 libraries.

I know of one exception to this: AIX.  I believe it possible to make a
library that would support both 1.4.1 and 1.3.5 on AIX, but you'd need
to be a bit of a wizard to do it.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: broken compatability between 1.3.5 and 1.4.1

Tim Mooney
In regard to: Re: broken compatability between 1.3.5 and 1.4.1, Sam Hartman...:

> we committed to an ABI for Unix, Mac and windows around 1.2.5.
>
> If you have an application using only symbols from that ABI (symbols
> defined in our header files without KRB5_PRIVATE defined) we would
> consider it a serious bug if such an application failed to link
> against 1.4.1 libraries when built against 1.3.5 libraries.

Older versions of Simon's patch for GSSAPI support in OpenSSH (in
the OpenSSH 3.5p1 timeframe, which was newer than 1.2.5) and the
perl5 module Authen-Krb5 (even version 1.4, which is recent) both call
krb5_init_ets().

It's this call that caused problems when I upgraded the krb5 shared
libraries from 1.2.8 to 1.4.x.  Of course you're correct that applications
shouldn't be using that (or any other KRB5_PRIVATE symbol) today, but some
still are.

Moreover, consider the situation where I build packages like Authen-Krb5
against krb5 1.2.4 (or some earlier version), where krb5_init_ets() was not
marked private, and was visible in the shared library.

Now I upgrade the shared libraries and headers to version 1.2.8.  What's
marked as private in the headers has changed, but the symbols in the library
are still visible, and the library advertises the same ABI.

Now I upgrade to 1.3.x or 1.4.x.  Oops.  The library says it's still the
same ABI as way back in the 1.2.x days, but suddenly lots of symbols
aren't resolvable by the runtime loader.

It's too late to really do anything about this for krb5_init_ets() and
friends, but in the future please at least consider whether an ABI bump
might be wise if you remove additional symbols from the shared libraries
(even if they're only symbols that people shouldn't be using).  I
understand that ABI bumps are a pain for system integrators and packagers,
and gratuitous bumps are to be avoided.  A library that says its
compatible with 1.2.4 but really isn't compatible is a pain, too, though.

Tim
--
Tim Mooney                              [hidden email]
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: broken compatability between 1.3.5 and 1.4.1

Roland C. Dowdeswell
In reply to this post by Tom Yu
On 1128121033 seconds since the Beginning of the UNIX epoch
Tom Yu wrote:
>

>Interesting.  As early as 1.2.x, the *_init_ets() functions were
>marked as private, so prototypes should not have been available unless
>KRB5_PRIVATE was defined.
>
>Also, somewhere since 1.2.x, we started to use export lists to
>restrict symbols exported from shared libraries on Unix platforms.

Not exposing the prototypes only helps if developers consistently
compile with [in gcc]: -Wmissing-prototypes -Werror.  Unfortunately,
most C programmers do not do this and hence continued to use the
function without being alerted to the fact that it was missing.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: broken compatability between 1.3.5 and 1.4.1

Andrew Bartlett
On Wed, 2005-10-05 at 15:44 -0400, Roland Dowdeswell wrote:

> On 1128121033 seconds since the Beginning of the UNIX epoch
> Tom Yu wrote:
> >
>
> >Interesting.  As early as 1.2.x, the *_init_ets() functions were
> >marked as private, so prototypes should not have been available unless
> >KRB5_PRIVATE was defined.
> >
> >Also, somewhere since 1.2.x, we started to use export lists to
> >restrict symbols exported from shared libraries on Unix platforms.
>
> Not exposing the prototypes only helps if developers consistently
> compile with [in gcc]: -Wmissing-prototypes -Werror.  Unfortunately,
> most C programmers do not do this and hence continued to use the
> function without being alerted to the fact that it was missing.
I note that (rightly or wrongly) Samba 3.0 has for a while defined
KRB5_PRIVATE and KRB5_DEPRICATED to get at functions it needs.  There
may be alternate ways to achieve the same goals, and it appears (because
we still link on my Fedora Core 4, krb5-1.4.1, apparently) we can still
get at them for the moment.  

I'm certainly worried (from the practical standpoint of existing
installations) if the list of hidden functions was to grow, and break
Samba installs.

As I have mentioned here before in Samba4 we have taken an entirely
different approach, and I hope this won't be an issue for that release.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: broken compatability between 1.3.5 and 1.4.1

hartmans
>>>>> "Andrew" == Andrew Bartlett <[hidden email]> writes:

    Andrew> I'm certainly worried (from the practical standpoint of
    Andrew> existing installations) if the list of hidden functions
    Andrew> was to grow, and break Samba installs.

We have committed to not hiding any symbols not already marked
krb5_private without an ABI bump.

If you're using krb5_private symbols, please talk to us about what
symbols you're using.

--Sam

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: broken compatability between 1.3.5 and 1.4.1

Paul Moore-3
In reply to this post by Paul Moore-3
Since I posted the original message in this thread I will update with my
exact errors

A) openssh crash
It calls krb5_init_ets - even in its very latest build. It does not
define KRB5_PRIVATE; it just calls the function and lets gcc moan about
the missing declaration
This causes the crash I see (compile with 1.3.5 run against 1.4.1)
Don't quite understand why it explodes (the function signature is the
same)


B) missing symbols
This was a result of running krb5 clients (klist, kinit, ....) with the
wrong libs
I suppose that this is expected behaviour - duuh


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Sam Hartman
Sent: Sunday, October 09, 2005 2:15 PM
To: Andrew Bartlett
Cc: Tim Mooney; Tom Yu; [hidden email]
Subject: Re: broken compatability between 1.3.5 and 1.4.1

>>>>> "Andrew" == Andrew Bartlett <[hidden email]> writes:

    Andrew> I'm certainly worried (from the practical standpoint of
    Andrew> existing installations) if the list of hidden functions
    Andrew> was to grow, and break Samba installs.

We have committed to not hiding any symbols not already marked
krb5_private without an ABI bump.

If you're using krb5_private symbols, please talk to us about what
symbols you're using.

--Sam

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev