Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Sat, Jul 17, 2010 at 08:55:54AM +0200, Joerg Pulz wrote: > i followed this thread so far and searched a little bit about the issue. > I also tested on my machines and came to an interesting point. > First my setup is pretty straight forward. > > Set HEIMDAL_HOME=/usr . > Build security/cyrus-sasl2 (OPTIONS don't matter i think). > Build net/openldap24-sasl-client (select SASL OPTION) > > If you don't have any accessible LDAP server on your net (OpenLDAP > or Windows AD doesn't matter) you have to build and just start one > for yourself. > > Afterwards just try the following command: > > ldapsearch -Ygssapi -h > > Now the interesting point. > On my amd64 system i get this after executing the above command: > > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: > Miscellaneous failure (see text) (unknown mech-code 2 for mech > unknown) > > While on my i386 system i get this: > > SASL/GSSAPI authentication started > Segmentation fault (core dumped) > > A quick look at the gdb bt of the core file looks like this: > > #0 0x28310ef5 in free () from /lib/libc.so.7 > #1 0x283fc972 in gss_release_buffer () from /usr/lib/libgssapi.so.10 > #2 0x283fc37e in gss_release_name () from /usr/lib/libgssapi.so.10 > #3 0x283f8da9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 > #4 0x283f1a0b in gssapi_client_mech_step () >from /usr/local/lib/sasl2/libgssapiv2.so.2 > #5 0x280ed4f4 in sasl_client_step () from /usr/local/lib/libsasl2.so.2 > > So i think i've hit the same bug all others are experiencing. > It looks like it is a i386 speciality but it can also be pure luck > an amd64. > I found at least one other report on the net which looks very > similar to what i see. i386 == Segmentation fault, amd64 == Error > message. > > Jeremy, is your test system running on amd64 or i386? The test system is amd64. I'm not doubting the issue may be more apparent/easier to occur on i386, but "pure luck on amd64" is a bit surprising. I'll build an i386 version of my testbox and start the procedure over again. -- | 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 | ___ 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"
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
I'll build an i386 version of my testbox and start the procedure over again. Just installed cyrus for testing into another i386 system and hit the same exact bug. I wonder if this is the reason for the problem we're encountering: http://www.freebsd.org/cgi/query-pr.cgi?pr=138929 "This patch updates the heimdal-1.0.1_1 port to heimdal-1.2.1. It "works for me" on 7.2/i386 and 8.0/i386 and passes portlint. I needed to upgrade to Heimdal 1.2.1 on 8.0-BETA2 (base Heimdal is 1.1.0) to get GSSAPI authenticaion to work (through SASL) for the OpenLDAP server." -Reko ___ 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"
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Sat, Jul 17, 2010 at 05:00:15PM +0300, Reko Turja wrote: > >I'll build an i386 version of my testbox and start the procedure > >over > >again. > > Just installed cyrus for testing into another i386 system and hit > the same exact bug. I wonder if this is the reason for the problem > we're encountering: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=138929 > > "This patch updates the heimdal-1.0.1_1 port to heimdal-1.2.1. It > "works > for me" on 7.2/i386 and 8.0/i386 and passes portlint. I needed to > upgrade to Heimdal 1.2.1 on 8.0-BETA2 (base Heimdal is 1.1.0) to get > GSSAPI authenticaion to work (through SASL) for the OpenLDAP server." Heimdal is a Kerberos thing. My test amd64 system I've been working on *does not* have security/heimdal installed. As stated a couple times before, these are the ports on the 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 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.15Checks installed ports against a list of security vulnerabi rsync-3.0.7 A network file distribution/synchronization utility vim-lite-7.2.411Vi "workalike", with many additional features (Lite package Furthermore, on this system Kerberos is not configured/set up. (I attempted to that following Henrik/KaarPoSoft's instructions but got stuck in a few places, so I reverted back to the above setup. This is why virtual machines + VM snapshot capability are useful. :-) ) The problem really looks to be with GSSAPI, which is part of the base system (src/lib/libgssapi). If I can reproduce the problem on the test i386 system I'm building, which will have the same port + configuration as the test amd64 system, then I would say it's purely a GSSAPI thing regardless if you're using GSSAPI w/ SASL or GSSAPI w/ Kerberos. -- | 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 | ___ 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"
SIGEPIPE after update to 8.1-RC2
Hi, stable After updating my buildbox from 26 April 8-STABLE to 8.1-RC2 I constantly getting SIGEPIPE portsnap: Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 27 patches.1020... done. Applying patches... done. Fetching 3 new ports or files... done. sort: write failed: standard output: Broken pipe sort: write error Removing old files and directories... done. sudo make -C /usr/ports/converters/ascii2binary: ===> Patching for ascii2binary-2.13_2 ===> Applying FreeBSD patches for ascii2binary-2.13_2 ===> ascii2binary-2.13_2 depends on shared library: intlgrep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe - found ===> Configuring for ascii2binary-2.13_2 Does anyone know something about this issue? -- Adios ___ 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"
Re: SIGEPIPE after update to 8.1-RC2
Try rebuilding bash or sh or whatever you are using as shell. I'm not sure though. Ronald. On Sat, 17 Jul 2010 17:24:55 +0200, Alex Kozlov wrote: Hi, stable After updating my buildbox from 26 April 8-STABLE to 8.1-RC2 I constantly getting SIGEPIPE portsnap: Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 27 patches.1020... done. Applying patches... done. Fetching 3 new ports or files... done. sort: write failed: standard output: Broken pipe sort: write error Removing old files and directories... done. sudo make -C /usr/ports/converters/ascii2binary: ===> Patching for ascii2binary-2.13_2 ===> Applying FreeBSD patches for ascii2binary-2.13_2 ===> ascii2binary-2.13_2 depends on shared library: intlgrep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe - found ===> Configuring for ascii2binary-2.13_2 Does anyone know something about this issue? -- Adios ___ 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" ___ 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"
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On 07/17/2010 07:41 AM, Jeremy Chadwick wrote: > The problem really looks to be with GSSAPI, which is part of the base > system (src/lib/libgssapi). > > If I can reproduce the problem on the test i386 system I'm building, > which will have the same port + configuration as the test amd64 system, > then I would say it's purely a GSSAPI thing regardless if you're using > GSSAPI w/ SASL or GSSAPI w/ Kerberos. 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. -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On Sat, Jul 17, 2010 at 11:15:42AM -0700, Benjamin Lee wrote: > On 07/17/2010 07:41 AM, Jeremy Chadwick wrote: > > The problem really looks to be with GSSAPI, which is part of the base > > system (src/lib/libgssapi). > > > > If I can reproduce the problem on the test i386 system I'm building, > > which will have the same port + configuration as the test amd64 system, > > then I would say it's purely a GSSAPI thing regardless if you're using > > GSSAPI w/ SASL or GSSAPI w/ Kerberos. > > Can you try reproducing the issue on 8-STABLE? As the thread has stated, I can't reproduce the problem on RELENG_8 amd64, but I'm still working on building the test i386 box to see if I can reproduce the issue. Please be aware the issue supposedly can be reproduced *without* use of Kerberos/Heimdal. > 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. -- | 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 | ___ 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"
Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?)
On 13.07.2010, at 16:02, Markus Gebert wrote: > Unfortunately, I have not been able to get anything useful out the svn commit > logs, which could explain this. Maybe someone else has an idea what could > have changed between 7 and 8 to break it, and again between 8 and CURRENT to > magically fix it again. I tracked this down further. I couldn't easily downgrade my 8.1 installation to see when the problem was introduced because the zpool version used is 14. So I tried to figure out, when the problem was solved in CURRENT. I started with the first possible revision that can boot off my v14 pool (r201143, Dec 28, zfs v14 commit). With this revision, I was able to trigger the MCE. Then I took some later revision (rev206010, Apr 1, chosen randomly), and I couldn't reproduce the problem. I started narrowing the revisions down until I found out, that while on r202386 I'm still able to trigger the MCE, r202387 seems to solve the problem on CURRENT: http://svn.freebsd.org/viewvc/base?view=revision&revision=202387 Since John Baldwin mentioned this problem could be timing related, it seems reasonable, that a clock-related change could be fix it. But this commit seems to have been MFC'd to 8-STABLE and 8.1 (at least as far as I can tell) along with some other changes to amd64 specific code. I thought that maybe these other changes that have been MFC'd could have reintroduced the problem later on, but so far I could not reproduce the problem with newer CURRENT revisions. So, I actually nailed this one done to a single commit on CURRENT, but still cannot tell what the actual difference is compared to 8-STABLE/8.1. Any ideas how to proceed? Markus___ 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"
Re: SIGEPIPE after update to 8.1-RC2
On Sat, Jul 17, 2010 at 06:58:29PM +0200, Ronald Klop wrote: > Try rebuilding bash or sh or whatever you are using as shell. I'm not sure > though. I done only preliminary testing, but replacing /bin/sh by one from 8.0-RELEASE seems to help. Thanks. Now I will try to find particular commit that broke sh. -- Adios ___ 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"
Re: SIGEPIPE after update to 8.1-RC2
On Sat, Jul 17, 2010 at 06:24:55PM +0300, Alex Kozlov wrote:
> After updating my buildbox from 26 April 8-STABLE
> to 8.1-RC2 I constantly getting SIGEPIPE
> portsnap:
> Fetching 4 metadata patches... done.
> Applying metadata patches... done.
> Fetching 0 metadata files... done.
> Fetching 27 patches.1020... done.
> Applying patches... done.
> Fetching 3 new ports or files... done.
> sort: write failed: standard output: Broken pipe
> sort: write error
> Removing old files and directories... done.
> sudo make -C /usr/ports/converters/ascii2binary:
> ===> Patching for ascii2binary-2.13_2
> ===> Applying FreeBSD patches for ascii2binary-2.13_2
> ===> ascii2binary-2.13_2 depends on shared library: intlgrep: writing
> output: Broken pipe
> grep: writing output: Broken pipe
[snip repetition]
> - found
> ===> Configuring for ascii2binary-2.13_2
> Does anyone know something about this issue?
This looks more like the absence of SIGPIPE than an inappropriate
SIGPIPE. I can reproduce both of those error messages by running the
commands with SIGPIPE ignored. grep(1) seems to behave strangely on
write errors, not aborting, for example
yes | { trap '' PIPE; grep -v foo; echo $? >&2; } | :
prints an endless stream of error messages.
Note that sh(1) silently ignores attempts to change the disposition of
signals that were ignored on entry to the shell, so a
trap - PIPE
is unlikely to help you.
Similarly, SIGPIPE may be blocked (masked). Few programs expect this.
The -i and -j options in procstat should be helpful in finding what
exactly is wrong with SIGPIPE. (These options are relatively new, but
should be in 8.1.)
--
Jilles Tjoelker
___
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"
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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. -Reko ___ 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"
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On 17.07.2010 09:41, Jeremy Chadwick wrote: The test system is amd64. I'm not doubting the issue may be more apparent/easier to occur on i386, but "pure luck on amd64" is a bit surprising. I'll build an i386 version of my testbox and start the procedure over again. Set the malloc(3) flags to paranoid (like "AJ" or "AZ"). You should then be able to reproduce it on any platform... Yours, -mi ___ 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"
Re: SIGEPIPE after update to 8.1-RC2
On 18/07/2010 1:24 AM, Alex Kozlov wrote: Hi, stable After updating my buildbox from 26 April 8-STABLE to 8.1-RC2 I constantly getting SIGEPIPE [snip] I'm getting the same thing; what shell are you using? I changed my shell on one machine from /bin/tcsh to /usr/local/bin/bash and problem disappeared. -- Adios ___ 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" ___ 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"
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 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.15Checks installed ports against a list of security vulnerabi rsync-3.0.7 A network file distribution/synchronization utility vim-lite-7.2.411Vi "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=1) 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. -- | 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 | ___ 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"
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 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.15Checks installed ports against a list of security > vulnerabi > rsync-3.0.7 A network file distribution/synchronization utility > vim-lite-7.2.411Vi "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=1) 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:
