On Sat, Jul 17, 2010 at 07:38:19PM -0700, Jeremy Chadwick wrote: > On Sun, Jul 18, 2010 at 01:37:06AM +0300, Reko Turja wrote: > > > > >Can you try reproducing the issue on 8-STABLE? > > > > > >I recently submitted a Heimdal patch against 8.1-STABLE and > > >9.0-CURRENT that resolves some libgssapi-related issues: > > > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454 > > > > > >The patch breaks ABI, so you'll have to rebuild libgssapi-dependent > > >applications. > > > > When linking cyrus-sasl2 against gssapi library from either the > > 1.0.1 official port or the inofficial 1.2.1 patchset cyradm works as > > expected and it logs a message from gssapi/kerberos telling that no > > KDC's are available - which is to be expected on a system that isn't > > using gssapi/kerberos in authenticating. > > > > So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday > > the 5th is clearly some kind of regression as system gsslib doesn't > > seem to recognize the mech used or segfaults. > > > > Benjamin, can you clarify how to apply your patch against the source > > tree - I tried 'patch < the_patchset.diff' in /usr/src but it just > > created a bunch of files in the /usr/src which I think isn't the > > intention. > > Those following this thread will be happy to hear that I'm able to > reproduce the problem on the i386 test box: > > testbox# pkg_info > cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 > protocols > cyrus-sasl-2.1.23 RFC 2222 SASL (Simple Authentication and Security Layer) > db41-4.1.25_4 The Berkeley DB package, revision 4.1 > libtool-2.2.6b Generic shared library support script > perl-5.10.1_1 Practical Extraction and Report Language > portaudit-0.5.15 Checks installed ports against a list of security > vulnerabi > rsync-3.0.7 A network file distribution/synchronization utility > vim-lite-7.2.411 Vi "workalike", with many additional features (Lite > package > > testbox# cyradm localhost > Segmentation fault (core dumped) > > Jul 17 19:35:40 testbox imap[72119]: executed > Jul 17 19:35:40 testbox imap[72119]: accepted connection > Jul 17 19:35:46 testbox kernel: pid 72118 (perl5.10.1), uid 0: exited on > signal 11 (core dumped) > > -rw------- 1 root wheel 4448256 Jul 17 19:35 perl5.10.1.core > > (gdb) bt > #0 free (ptr=0x280861c0) at /usr/src/lib/libc/stdlib/malloc.c:3890 > #1 0x287edce2 in gss_release_buffer (minor_status=0xbfbfe698, > buffer=0x280861cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41 > #2 0x287ed6b2 in _gss_mg_error (m=0x28455bc0, maj=851968, min=2) at > /usr/src/lib/libgssapi/gss_display_status.c:240 > #3 0x287ea009 in gss_init_sec_context (minor_status=0xbfbfe7a8, > initiator_cred_handle=0x0, context_handle=0x28837354, > target_name=0x285bff60, input_mech_type=0x0, req_flags=58, time_req=0, > input_chan_bindings=0x0, input_token=0x0, > actual_mech_type=0x0, output_token=0xbfbfe790, ret_flags=0xbfbfe7a0, > time_rec=0x0) > at /usr/src/lib/libgssapi/gss_init_sec_context.c:156 > #4 0x287e1aef in gssapi_client_mech_step (conn_context=0x28837350, > params=0x2841e480, serverin=0x0, serverinlen=0, > prompt_need=0xbfbfea70, clientout=0xbfbfea6c, clientoutlen=0xbfbfea68, > oparams=0x2846b860) at gssapi.c:1418 > #5 0x283ef591 in sasl_client_step (conn=0x2846b000, serverin=0x0, > serverinlen=0, prompt_need=0xbfbfea70, clientout=0xbfbfea6c, > clientoutlen=0xbfbfea68) at client.c:655 > #6 0x283f0215 in sasl_client_start (conn=0x2846b000, mechlist=0x288878c0 > "GSSAPI ", prompt_need=0xbfbfea70, clientout=0xbfbfea6c, > clientoutlen=0xbfbfea68, mech=0xbfbfea78) at client.c:603 > #7 0x2832ab1a in imclient_authenticate (imclient=0x288b4000, > mechlist=0x28887880 "GSSAPI ", service=0x288877e8 "imap", > user=0x28801754 "", minssf=0, maxssf=10000) at imclient.c:1288 > #8 0x28327131 in XS_Cyrus__IMAP__authenticate () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so > #9 0x2811d2e5 in Perl_pp_entersub () from > /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #10 0x2811b7e5 in Perl_runops_standard () from > /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #11 0x280c20d4 in perl_run () from > /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #12 0x08048944 in main () > > I'll poke more at this.
Problem solved. Same i386 box: testbox# uname -a FreeBSD testbox.home.lan 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Sat Jul 17 18:46:34 PDT 2010 r...@testbox.home.lan:/usr/obj/usr/src/sys/TESTBOX i386 testbox# ls -l /usr/lib/libgssapi.so* lrwxr-xr-x 1 root wheel 15 Jul 17 19:47 /usr/lib/libgssapi.so -> libgssapi.so.10 -r--r--r-- 1 root wheel 1702244 Jul 17 19:47 /usr/lib/libgssapi.so.10 testbox# cyradm localhost Login disabled. cyradm: cannot authenticate to server with as root Jul 17 19:48:51 testbox master[72266]: about to exec /usr/local/cyrus/bin/imapd Jul 17 19:48:51 testbox imap[72266]: executed Jul 17 19:48:51 testbox imap[72266]: accepted connection Jul 17 19:48:51 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 17 19:48:51 testbox kernel: Jul 17 19:48:51 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 17 19:48:51 testbox perl: No worthy mechs found Jul 17 19:48:51 testbox kernel: Jul 17 19:48:51 testbox perl: No worthy mechs found I then tested the same patch on amd64 -- it also works. Again, this has only been tested on RELENG_8. Methodology for patching/fixing is simple: cd /usr/src patch -p0 < /path/to/patch cd lib/libgssapi make make install Then restart any daemons which link to libgssapi or any of the related libgssapi_xxx libraries (you can use ldd to determine this). In the above case, all I had restart was imapd. You *do not* need to rebuild software which is reliant upon libgssapi; the function semantics/API hasn't changed, just the code within one of the functions (gss_release_buffer()). There's no need to bump the library version number either because of this. As far as why it's more prevalent on i386 than amd64: a disassembly would probably help explain that. But to be honest, the last time I worked with x86 assembly was back in the 386/very early 486 days, and that was pure protected mode programming (not under *IX). There's basically little to no chance I'd understand the disassembly here. Someone else would have to delve into it. People who have open PRs on this matter -- please feel free to reference this thread, and/or the below patch, in your PRs. I've also put the patch up on my website for easy fetching: http://jdc.parodius.com/freebsd/gss_release_buffer.c.patch Cheers! -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | --- lib/libgssapi/gss_release_buffer.c.orig 2009-08-03 01:13:06.000000000 -0700 +++ lib/libgssapi/gss_release_buffer.c 2010-07-17 19:47:25.000000000 -0700 @@ -37,7 +37,7 @@ { *minor_status = 0; - if (buffer->value) + if (buffer->length && buffer->value) free(buffer->value); _gss_buffer_zero(buffer); _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
