Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-18 Thread Reko Turja 
Applying Benjamin's patch to RELENG_8 sources csupped yesterday stops 
the buildworld in last library stage:


In file included from /usr/src/lib/libc/rpc/clnt_dg.c:55:
/usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:52: error: expected 
specifier-qualifier-list before 'gss_cred_id_t'
/usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:65: error: expected 
specifier-qualifier-list before 'gss_ctx_id_t'
/usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:119: error: expected 
declaration specifiers or '...' before 'gss_cred_id_t'
/usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:120: error: expected 
declaration specifiers or '...' before 'gss_ctx_id_t'
/usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:149: error: expected 
declaration specifiers or '...' before 'gss_OID'
/usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:150: error: expected 
')' before 'oid'

*** Error code 1

Stop in /usr/src/lib/libc.
*** Error code 1

Tried to poke around a bit but I was unable to find declarations for 
the missing types. How to proceed if I want to test the patch?


-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

2010-07-18 Thread Reko Turja 
After manually changing the gssapi header used in 
/usr/src/include/rpc/rpcsec_gss.h to somewhat klunky #include 
/usr/src/crypto/heimdal/lib/gssapi/gssapi/gssapi.h system csupped 
yesterday built okay and after rebuilding cyrus-sasl, saslauthd and 
cyrus I get the following failures in log:


Jul 18 16:37:35 moria perl: GSSAPI Error:  Miscellaneous failure (see 
text)^B (open(/tmp/krb5cc_0): No such file or directory)


-This is expected behaviour as Kerberos was not running at the moment, 
but with Benjamin's patch Kerberos/GSSAPI spat out a meaningful error 
message


After dusting off my old Kerberos setup, doing basic kinit and running 
cyradm localhost I got:


Jul 18 16:39:00 moria perl: GSSAPI Error:  Miscellaneous failure (see 
text) (Server (imap/localh...@xxx.domain.com) unknown)


-Again expected as there is no imap trust relationship defined.

So at least after cursory testing it looks like that with Benjamin's 
patch there is a working GSSAPI/Kerberos backend available, instead of 
something that chokes on passed parameters that are ok for every other 
tested gssapi implementation.


Of course, more thorough testing in proper kerberised/LDAP environment 
needs to be done, which is something I haven't got time at the moment.


-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

2010-07-18 Thread Benjamin Lee 
On 07/17/2010 03:37 PM, 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.

Hi Reko,

It looks like you've already figured it out (based on your responses
elsewhere in the thread), but for the record you can apply the patch by
running:

cd /usr/src
patch -p1 -E  foo.diff

That patch is over a month old now and no longer applies cleanly.  I'll
port it forward when I get a chance.


-- 
Benjamin Lee
http://www.b1c1l1.com/



signature.asc
Description: OpenPGP digital signature

Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-18 Thread Benjamin Lee 
On 07/18/2010 06:52 AM, Reko Turja wrote:
 After manually changing the gssapi header used in
 /usr/src/include/rpc/rpcsec_gss.h to somewhat klunky #include
 /usr/src/crypto/heimdal/lib/gssapi/gssapi/gssapi.h system csupped
 yesterday built okay and after rebuilding cyrus-sasl, saslauthd and
 cyrus I get the following failures in log:
 
 Jul 18 16:37:35 moria perl: GSSAPI Error:  Miscellaneous failure (see
 text)^B (open(/tmp/krb5cc_0): No such file or directory)
 
 -This is expected behaviour as Kerberos was not running at the moment,
 but with Benjamin's patch Kerberos/GSSAPI spat out a meaningful error
 message
 
 After dusting off my old Kerberos setup, doing basic kinit and running
 cyradm localhost I got:
 
 Jul 18 16:39:00 moria perl: GSSAPI Error:  Miscellaneous failure (see
 text) (Server (imap/localh...@xxx.domain.com) unknown)
 
 -Again expected as there is no imap trust relationship defined.
 
 So at least after cursory testing it looks like that with Benjamin's
 patch there is a working GSSAPI/Kerberos backend available, instead of
 something that chokes on passed parameters that are ok for every other
 tested gssapi implementation.
 
 Of course, more thorough testing in proper kerberised/LDAP environment
 needs to be done, which is something I haven't got time at the moment.

Thanks for your testing!

Based on the lack of attention my PR has received it seems that not many
people have noticed the regression in libgssapi, even though the
breaking commit happened in -CURRENT way back in 2008.

When you get a chance, please append your test results to PR
kern/147454.  That may be helpful in attracting some more attention to
this issue.


-- 
Benjamin Lee
http://www.b1c1l1.com/



signature.asc
Description: OpenPGP digital signature

Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-17 Thread Joerg Pulz 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Fri, 16 Jul 2010, Jeremy Chadwick wrote:


On Fri, Jul 16, 2010 at 03:58:04PM +0300, Reko Turja wrote:

I think we need the OP of the PR[1], Mikhail T., to chime in here
with his
setup.


While waiting, can you test the following: In the
/usr/local/etc/imapd.conf file comment out

#sasl_pwcheck_method: saslauthd

and add below it:

sasl_mech_list: gssapi pam plain


Thanks -- I did so + restarted imapd, and now we have:

testbox# cyradm localhost
Login disabled.
cyradm: cannot authenticate to server with  as root

Jul 16 06:46:02 testbox master[11087]: about to exec /usr/local/cyrus/bin/imapd
Jul 16 06:46:02 testbox imap[11087]: executed
Jul 16 06:46:02 testbox imap[11087]: accepted connection
Jul 16 06:46:02 testbox perl: GSSAPI Error:  Miscellaneous failure (see text) 
(unknown mech-code 2 for mech unknown)
Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: GSSAPI Error:  
Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown)
Jul 16 06:46:02 testbox perl: No worthy mechs found
Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: No worthy mechs 
found


Jeremy,

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 LDAP server hostname

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?

Kind regards
Joerg

- -- 
The beginning is the most important part of the work.

-Plato
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (FreeBSD)

iD8DBQFMQVP9SPOsGF+KA+MRAn3OAJ4r5fqAoOjpMWBvEdHKAE9h8cROFgCfU/DI
Hm8AsO4vdgGCdWUgdJ6mRTs=
=nTdu
-END PGP SIGNATURE-
___
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

2010-07-17 Thread Jeremy Chadwick 
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 LDAP server hostname
 
 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

2010-07-17 Thread Reko Turja 
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

2010-07-17 Thread Jeremy Chadwick 
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

Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-17 Thread Benjamin Lee 
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

2010-07-17 Thread Jeremy Chadwick 
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: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-17 Thread Reko Turja 



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

2010-07-17 Thread Mikhail T. 

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: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-17 Thread Jeremy Chadwick 
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

2010-07-17 Thread Jeremy Chadwick 
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:51 testbox imap[72266]: accepted connection
Jul 17 19:48:51 testbox perl: GSSAPI Error:  Miscellaneous failure (see text) 
(unknown

Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-16 Thread Jeremy Chadwick 
On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote:
 Furthermore, relevant bug (PR 144754) indicates there's an easier way to
 induce this problem, so I'm going to see if I can reproduce it here
 locally.  It's almost certainly the same problem but induced via a
 slightly different context.
 
 http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html
 
 I'll report back once I poke around with that.

I've tried to reproduce what's in the PR and can't.  Running cyradm
works fine:

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
cyradm

I should note this machine **does** have Kerberos installed as part of
the FreeBSD base system (meaning src.conf does not contain
WITHOUT_KERBEROS).

Mikhail, is there something I need to configure within cyrus-imapd23
first?  Three things to note:

1) I didn't modify /usr/local/etc/cyrus.conf or imapd.conf.
2) I have not started the imapd service.
3) /var/log/all.log shows the following errors (but the daemon starts
anyway):

Jul 15 23:25:25 testbox master[46529]: process started
Jul 15 23:25:25 testbox master[46530]: about to exec 
/usr/local/cyrus/bin/ctl_cyrusdb
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db: No such 
file or directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db/__db.001: 
No such file or directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db: No such 
file or directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db/__db.001: 
No such file or directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: dbenv-open '/var/imap/db' 
failed: No such file or directory
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: 
DBERROR: dbenv-open '/var/imap/db' failed: No such file or directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on berkeley
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: 
DBERROR: init() on berkeley
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: writing 
/var/imap/db/skipstamp: No such file or directory
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: 
DBERROR: writing /var/imap/db/skipstamp: No such file or directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on skiplist
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: 
DBERROR: init() on skiplist
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: recovering cyrus databases
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: IOERROR: creating directory 
/var/imap: Permission denied
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: 
IOERROR: creating directory /var/imap: Permission denied
Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: opening /var/imap: cyrusdb 
error
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: 
DBERROR: opening /var/imap: cyrusdb error
Jul 15 23:25:25 testbox master[46529]: process 46530 exited, status 75
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox master[46529]: process 
46530 exited, status 75
Jul 15 23:25:25 testbox master[46529]: unable to create lmtpunix listener 
socket: No such file or directory
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox master[46529]: unable 
to create lmtpunix listener socket: No such file or directory
Jul 15 23:25:25 testbox master[46529]: ready for work
Jul 15 23:25:25 testbox master[46531]: about to exec 
/usr/local/cyrus/bin/ctl_cyrusdb
Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: /var/imap/db/__db.001: 
No such file or directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: dbenv-open '/var/imap/db' 
failed: No such file or directory
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: 
DBERROR: dbenv-open '/var/imap/db' failed: No such file or directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: init() on berkeley
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: 
DBERROR: init() on berkeley
Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: reading 
/var/imap/db/skipstamp, assuming the worst: No such file or directory
Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: 
DBERROR: reading /var/imap/db/skipstamp, assuming the worst: No such file or 
directory
Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: checkpointing cyrus databases
Jul 15 23:25:25 testbox

Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-16 Thread Reko Turja 

On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote:
Furthermore, relevant bug (PR 144754) indicates there's an easier 
way to

induce this problem, so I'm going to see if I can reproduce it here
locally.  It's almost certainly the same problem but induced via a
slightly different context.

http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html

I'll report back once I poke around with that.



testbox# cyradm
cyradm


Try giving command cyradm localhost instead - the cyradm without 
connection starts, but trying to connect to the local server triggers 
the bug. Or you can give 'server localhost' instead from the cyradm 
command line.


I should note this machine **does** have Kerberos installed as part 
of

the FreeBSD base system (meaning src.conf does not contain
WITHOUT_KERBEROS).


Similar as my setup - kerberos isn't excluded even if it's not really 
used.



Mikhail, is there something I need to configure within cyrus-imapd23
first?  Three things to note:

1) I didn't modify /usr/local/etc/cyrus.conf or imapd.conf.
2) I have not started the imapd service.
3) /var/log/all.log shows the following errors (but the daemon 
starts

anyway):



Let me know as I'm doing my best to track this down.  Thanks.


Another datapoint that might or might not have some connection with 
the issue is that in _gss_mg_error (m=0x28a86480, maj=851968, min=2) 
at /usr/src/lib/libgssapi/gss_display_status.c


void
232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj, 
OM_uint32 min)

233 {
234 OM_uint32 major_status, minor_status;
235 OM_uint32 message_content;
236 struct mg_thread_ctx *mg;
237
238 mg = last_error_context;
239
240 gss_release_buffer(minor_status, mg-maj_error);
241 gss_release_buffer(minor_status, mg-min_error);
242
243 mg-mech = m-gm_mech_oid;
244 mg-maj_stat = maj;

when I give following comands, gdb tells me:

(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p mg
No symbol mg in current context.
(gdb)

Thank you very much for your effort in the issue!

-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

2010-07-16 Thread Jeremy Chadwick 
On Fri, Jul 16, 2010 at 11:56:17AM +0300, Reko Turja wrote:
 Another datapoint that might or might not have some connection with
 the issue is that in _gss_mg_error (m=0x28a86480, maj=851968, min=2)
 at /usr/src/lib/libgssapi/gss_display_status.c
 
 void
 232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj,
 OM_uint32 min)
 233 {
 234 OM_uint32 major_status, minor_status;
 235 OM_uint32 message_content;
 236 struct mg_thread_ctx *mg;
 237
 238 mg = last_error_context;
 239
 240 gss_release_buffer(minor_status, mg-maj_error);
 241 gss_release_buffer(minor_status, mg-min_error);
 242
 243 mg-mech = m-gm_mech_oid;
 244 mg-maj_stat = maj;
 
 when I give following comands, gdb tells me:
 
 (gdb) p last_error_context
 Cannot find thread-local variables on this target
 (gdb) p last_error_context
 Cannot find thread-local variables on this target
 (gdb) p mg
 No symbol mg in current context.
 (gdb)

I'm not sure if you're familiar with C or not.

This is because gdb's context is at the wrong frame.  In the backtrace
you provided originally, you'd need to do:

(gdb) frame 2

To look at the variables associated with gss_display_status.c.

last_error_context could be an exported variable (you'd need to look
through the source to find out where it's declared), so you might have
to print it with its source filename referenced.  The print command I
gave you before (p/x filename.c::variable) didn't work, and that's a
surprise since the gdb documentation I read says it should.

Also be aware that mg is a struct, so p mg won't tell you much, other
than whether or not it's null.  You're probably more interested in
members of the struct, such as mg-maj_error and mg-min_error, and
other struct members.

-- 
| 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

2010-07-16 Thread Jeremy Chadwick 
On Fri, Jul 16, 2010 at 11:56:17AM +0300, Reko Turja wrote:
 On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote:
 Furthermore, relevant bug (PR 144754) indicates there's an
 easier way to
 induce this problem, so I'm going to see if I can reproduce it here
 locally.  It's almost certainly the same problem but induced via a
 slightly different context.
 
 http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html
 
 I'll report back once I poke around with that.
 
 testbox# cyradm
 cyradm
 
 Try giving command cyradm localhost instead - the cyradm without
 connection starts, but trying to connect to the local server
 triggers the bug. Or you can give 'server localhost' instead from
 the cyradm command line.

This doesn't help.  The problem is that Cyrus imapd is completely
freaking out, continually dying and re-forking itself, with my kernel
message buffer filling rapidly + all.log filling.  So, there is further
configuration of this daemon that's needed (meaning it does not work
straight out of the box), and I need those configuration details.

Proof -- note the imapd pid changing constantly:

testbox# ps -auxw | grep cyrus
cyrus 46529  5.0  0.4 22376  3920  ??  Rs   11:25PM   0:05.36 
/usr/local/cyrus/bin/master -d
cyrus 51859  0.0  0.4 22376  3920  ??  R12:14AM   0:00.00 
/usr/local/cyrus/bin/master -d
testbox# ps -auxw | grep cyrus
cyrus 46529  6.0  0.4 22376  3920  ??  Ss   11:25PM   0:05.43 
/usr/local/cyrus/bin/master -d
cyrus 51928  0.0  0.3 22512  3572  ??  R12:15AM   0:00.02 imapd
testbox# ps -auxw | grep cyrus
cyrus 46529  6.0  0.4 22376  3920  ??  Ss   11:25PM   0:05.55 
/usr/local/cyrus/bin/master -d
cyrus 52046  0.0  0.1  1560  1360  ??  R12:15AM   0:00.00 imapd
testbox# ps -auxw | grep cyrus
cyrus 46529  6.0  0.4 22376  3920  ??  Ss   11:25PM   0:05.61 
/usr/local/cyrus/bin/master -d
cyrus 52114  0.0  0.1  1560  1360  ??  R12:15AM   0:00.00 imapd


-- 
| 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

2010-07-16 Thread Reko Turja 

This doesn't help.  The problem is that Cyrus imapd is completely
freaking out, continually dying and re-forking itself, with my 
kernel
message buffer filling rapidly + all.log filling.  So, there is 
further

configuration of this daemon that's needed (meaning it does not work
straight out of the box), and I need those configuration details.


Below is the relevant parts of my config that should get you going:

my /usr/local/etc/cyrus.conf:

START {
 # do not delete this entry!
 recover   cmd=ctl_cyrusdb -r

 # this is only necessary if using idled for IMAP IDLE
 idled cmd=idled
}

# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
 # add or remove based on preferences
 imap cmd=imapd -C  /usr/local/etc/imapd.conf listen=imap 
prefork=0

#  pop3 cmd=pop3d listen=pop3 prefork=0
#  pop3scmd=pop3d -s listen=pop3s prefork=0
 sieve cmd=timsieved listen=sieve prefork=0

 # at least one LMTP is required for delivery
#  lmtp cmd=lmtpd listen=lmtp prefork=0
 lmtpunix  cmd=/usr/local/cyrus/bin/lmtpd 
listen=/var/imap/socket/lmtp prefork=0


 # this is only necessary if using notifications
 notifycmd=notifyd listen=/var/imap/socket/notify 
proto=udp prefork=1

}

EVENTS {
 # this is required
 checkpointcmd=ctl_cyrusdb -c period=30

 # this is only necessary if using duplicate delivery suppression
 delprune  cmd=cyr_expire -E 3 at=0400


 # this is only necessary if caching TLS sessions
 tlsprune  cmd=tls_prune period=1440
}


And /usr/local/etc/imapd.conf

#
# $FreeBSD: ports/mail/cyrus-imapd2/files/imapd.conf,v 1.8 2002/08/08 
14:06:48 ume Exp $

#
# Sample configurations file for Cyrus IMAPd
# Most lines in this file are commented; in this case the default is 
used.

# The commented lines (usually) contain the default value
configdirectory: /var/imap
partition-default: /usr/local/imap
unixhierarchysep: yes
lmtp_downcase_rcpt: yes
imap_allowanonymouslogin: no
sieve_allowanonymouslogin: no
imap_allowplaintext: no
sieve_allowplaintext: yes
imapidresponse: yes
admins: cyrus toor
autocreatequota: -128
duplicatesuppression: yes
sendmail: /usr/local/sbin/sendmail
postmaster: postmaster
sieve_maxscripts: 15
sasl_maximum_layer: 256
sasl_minimum_layer: 0
sasl_pwcheck_method: saslauthd
sasl_auto_transition: yes
lmtpsocket: /var/imap/socket/lmtp
idlesocket: /var/imap/socket/idle
notifysocket: /var/imap/socket/notify
#
# EOF

In addition, check that you have the following directories created + 
run the mkimap for creating the rest of directories/db's


Create the configuration directory specified by the configdirectory 
option in imapd.conf. The configuration directory is similar in 
concept to the /usr/lib/news directory. It stores information about 
the IMAP server as a whole.
This document uses the configuration directory /var/imap in its 
examples. This directory should be owned by the cyrus user and group 
and should not permit access to other users.


  cd /var
  mkdir imap
  chown cyrus imap
  chgrp mail imap
  chmod 750 imap

Create the default partition directories specified in the 
/etc/imapd.conf file.
This document uses a default partition directory of /var/spool/imap 
in the following example:


  cd /var/spool
  mkdir imap
  chown cyrus imap
  chgrp mail imap
  chmod 750 imap

Change to the Cyrus user and use the tool tools/mkimap to create the 
rest of the directories (subdirectories of the directories you just 
created).

  su cyrus
  tools/mkimap
  exit

Hope this helps

-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

2010-07-16 Thread Reko Turja 

void
232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj,
OM_uint32 min)
233 {
234 OM_uint32 major_status, minor_status;
235 OM_uint32 message_content;
236 struct mg_thread_ctx *mg;
237
238 mg = last_error_context;
239
240 gss_release_buffer(minor_status, mg-maj_error);
241 gss_release_buffer(minor_status, mg-min_error);
242
243 mg-mech = m-gm_mech_oid;
244 mg-maj_stat = maj;

when I give following comands, gdb tells me:

(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p mg
No symbol mg in current context.
(gdb)


I'm not sure if you're familiar with C or not.

This is because gdb's context is at the wrong frame.  In the 
backtrace

you provided originally, you'd need to do:

(gdb) frame 2

To look at the variables associated with gss_display_status.c.

last_error_context could be an exported variable (you'd need to look
through the source to find out where it's declared), so you might 
have
to print it with its source filename referenced.  The print command 
I

gave you before (p/x filename.c::variable) didn't work, and that's a
surprise since the gdb documentation I read says it should.

Also be aware that mg is a struct, so p mg won't tell you much, 
other

than whether or not it's null.  You're probably more interested in
members of the struct, such as mg-maj_error and mg-min_error, and
other struct members.


I gave f 2 before entering the commands above, and unless I'm much 
mistaken, 'p mg' should at least give the pointer to the start of the 
struct in question, so 'No symbol mg in current context' is mildly 
interesting reply from GDB :) If I understand the code in question 
right the last_error_context's address should be copied to mg for 
accessing the error structure defined elsewhere in the scope of the 
while.


the definition is in same file and is as follows:

176 #if defined(__sparc64__) || defined(__arm__) || 
defined(__mips__)

177
178 /*
179  * These platforms don't support TLS on FreeBSD - threads will 
just

180  * have to step on each other's error values for now.
181  */
182 #define __thread
183
184 #endif
185
186 struct mg_thread_ctx {
187 gss_OID mech;
188 OM_uint32 maj_stat;
189 OM_uint32 min_stat;
190 gss_buffer_desc maj_error;
191 gss_buffer_desc min_error;
192 };
193 static __thread struct mg_thread_ctx last_error_context

-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

2010-07-16 Thread Jeremy Chadwick 
On Fri, Jul 16, 2010 at 12:43:22PM +0300, Reko Turja wrote:
 This doesn't help.  The problem is that Cyrus imapd is completely
 freaking out, continually dying and re-forking itself, with my
 kernel
 message buffer filling rapidly + all.log filling.  So, there is
 further
 configuration of this daemon that's needed (meaning it does not work
 straight out of the box), and I need those configuration details.
 
 Below is the relevant parts of my config that should get you going:
 [...]

Thanks.  Most of this worked, except the following:

 And /usr/local/etc/imapd.conf
 [...]
 partition-default: /usr/local/imap
 [...]
 Change to the Cyrus user and use the tool tools/mkimap to create
 the rest of the directories (subdirectories of the directories you
 just created).
   su cyrus
   tools/mkimap
   exit

I changed partition-default to /var/spool/imap, which I think is what
was needed, otherwise mkimap complained about being unable to create
/usr/local/imap.

Also, for the su portion, I had to do:

# su cyrus
% cd /usr/local/cyrus
% bin/mkimap

Which worked.  I hope this was the right thing to do.

However, upon startup, I now see the following in all.log:

Jul 16 03:56:12 testbox master[1521]: process started
Jul 16 03:56:12 testbox master[1522]: about to exec 
/usr/local/cyrus/bin/ctl_cyrusdb
Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: recovering cyrus databases
Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: done recovering cyrus databases
Jul 16 03:56:12 testbox master[1523]: about to exec /usr/local/cyrus/bin/idled
Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for 
startup: No such file or directory
Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1523]: can't 
exec /usr/local/cyrus/bin/idled for startup: No such file or directory
Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71
Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1521]: process 
1523 exited, status 71

Which is true:

testbox# find /usr/local -name idled -follow -ls
testbox#

I'm not sure if this feature is needed for reproducing the crash, so I
modified cyrus.conf and commented the line out, then restarted imapd,
which got me:

Jul 16 04:00:22 testbox master[1594]: process started
Jul 16 04:00:22 testbox master[1595]: about to exec 
/usr/local/cyrus/bin/ctl_cyrusdb
Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: recovering cyrus databases
Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed 
/var/imap/mailboxes.db (0 records, 144 bytes) in 0 seconds
Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed 
/var/imap/annotations.db (0 records, 144 bytes) in 0 seconds
Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: done recovering cyrus databases
Jul 16 04:00:22 testbox master[1594]: ready for work
Jul 16 04:00:22 testbox master[1596]: about to exec 
/usr/local/cyrus/bin/ctl_cyrusdb
Jul 16 04:00:22 testbox master[1597]: about to exec /usr/local/cyrus/bin/notifyd
Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: checkpointing cyrus databases
Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: 
/var/imap/annotations.db
Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: 
/var/imap/db/log.01
Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: 
/var/imap/db/log.01
Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: 
/var/imap/mailboxes.db
Jul 16 04:00:22 testbox notify[1597]: executed
Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: 
/var/imap/db/log.01
Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: 
/var/imap/db/log.01
Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: done checkpointing cyrus databases
Jul 16 04:00:22 testbox master[1594]: process 1596 exited, status 0

testbox# ps -auxw | grep cyrus
cyrus  1594  0.0  0.4 22376  3916  ??  Ss4:00AM   0:00.01 
/usr/local/cyrus/bin/master -d
cyrus  1597  0.0  0.4 53292  4412  ??  I 4:00AM   0:00.01 notifyd

testbox# sockstat -l | grep cyrus
cyrusnotifyd1597  4  dgram  /var/imap/socket/notify
cyrusmaster 1594  7  tcp4   *:143 *:*
cyrusmaster 1594  10 tcp4   *:4190*:*
cyrusmaster 1594  13 stream /var/imap/socket/lmtp
cyrusmaster 1594  16 dgram  /var/imap/socket/notify

Then for the final test:

testbox# cyradm
cyradm quit
testbox# cyradm localhost
Password:

Where I hit enter/blank, which got me:

Login disabled.
cyradm: cannot authenticate to server with  as root
testbox#

And no sign of a crash.

So what's next?

-- 
| 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

Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-16 Thread Jeremy Chadwick 
On Fri, Jul 16, 2010 at 04:04:27AM -0700, Jeremy Chadwick wrote:
 On Fri, Jul 16, 2010 at 12:43:22PM +0300, Reko Turja wrote:
  This doesn't help.  The problem is that Cyrus imapd is completely
  freaking out, continually dying and re-forking itself, with my
  kernel
  message buffer filling rapidly + all.log filling.  So, there is
  further
  configuration of this daemon that's needed (meaning it does not work
  straight out of the box), and I need those configuration details.
  
  Below is the relevant parts of my config that should get you going:
  [...]
 
 Thanks.  Most of this worked, except the following:
 
  And /usr/local/etc/imapd.conf
  [...]
  partition-default: /usr/local/imap
  [...]
  Change to the Cyrus user and use the tool tools/mkimap to create
  the rest of the directories (subdirectories of the directories you
  just created).
su cyrus
tools/mkimap
exit
 
 I changed partition-default to /var/spool/imap, which I think is what
 was needed, otherwise mkimap complained about being unable to create
 /usr/local/imap.
 
 Also, for the su portion, I had to do:
 
 # su cyrus
 % cd /usr/local/cyrus
 % bin/mkimap
 
 Which worked.  I hope this was the right thing to do.
 
 However, upon startup, I now see the following in all.log:
 
 Jul 16 03:56:12 testbox master[1521]: process started
 Jul 16 03:56:12 testbox master[1522]: about to exec 
 /usr/local/cyrus/bin/ctl_cyrusdb
 Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: recovering cyrus databases
 Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: done recovering cyrus databases
 Jul 16 03:56:12 testbox master[1523]: about to exec /usr/local/cyrus/bin/idled
 Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled 
 for startup: No such file or directory
 Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1523]: can't 
 exec /usr/local/cyrus/bin/idled for startup: No such file or directory
 Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71
 Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1521]: process 
 1523 exited, status 71
 
 Which is true:
 
 testbox# find /usr/local -name idled -follow -ls
 testbox#
 
 I'm not sure if this feature is needed for reproducing the crash, so I
 modified cyrus.conf and commented the line out, then restarted imapd,
 which got me:
 
 Jul 16 04:00:22 testbox master[1594]: process started
 Jul 16 04:00:22 testbox master[1595]: about to exec 
 /usr/local/cyrus/bin/ctl_cyrusdb
 Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: recovering cyrus databases
 Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed 
 /var/imap/mailboxes.db (0 records, 144 bytes) in 0 seconds
 Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed 
 /var/imap/annotations.db (0 records, 144 bytes) in 0 seconds
 Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: done recovering cyrus databases
 Jul 16 04:00:22 testbox master[1594]: ready for work
 Jul 16 04:00:22 testbox master[1596]: about to exec 
 /usr/local/cyrus/bin/ctl_cyrusdb
 Jul 16 04:00:22 testbox master[1597]: about to exec 
 /usr/local/cyrus/bin/notifyd
 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: checkpointing cyrus databases
 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: 
 /var/imap/annotations.db
 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: 
 /var/imap/db/log.01
 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: 
 /var/imap/db/log.01
 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: 
 /var/imap/mailboxes.db
 Jul 16 04:00:22 testbox notify[1597]: executed
 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: 
 /var/imap/db/log.01
 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: 
 /var/imap/db/log.01
 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: done checkpointing cyrus databases
 Jul 16 04:00:22 testbox master[1594]: process 1596 exited, status 0
 
 testbox# ps -auxw | grep cyrus
 cyrus  1594  0.0  0.4 22376  3916  ??  Ss4:00AM   0:00.01 
 /usr/local/cyrus/bin/master -d
 cyrus  1597  0.0  0.4 53292  4412  ??  I 4:00AM   0:00.01 notifyd
 
 testbox# sockstat -l | grep cyrus
 cyrusnotifyd1597  4  dgram  /var/imap/socket/notify
 cyrusmaster 1594  7  tcp4   *:143 *:*
 cyrusmaster 1594  10 tcp4   *:4190*:*
 cyrusmaster 1594  13 stream /var/imap/socket/lmtp
 cyrusmaster 1594  16 dgram  /var/imap/socket/notify
 
 Then for the final test:
 
 testbox# cyradm
 cyradm quit
 testbox# cyradm localhost
 Password:
 
 Where I hit enter/blank, which got me:
 
 Login disabled.
 cyradm: cannot authenticate to server with  as root
 testbox#
 
 And no sign of a crash.
 
 So what's next?

I forgot to check all.log.  It contains errors.  Hopefully someone will
know what to do about this:

Jul 16 04:03:50 testbox imap[1619]: executed
Jul 16 04:03:50 testbox imap[1619]: accepted connection
Jul 16 04:03:50 testbox imap[1619]: OTP

Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-16 Thread Reko Turja 

Thanks.  Most of this worked, except the following:

[SNIP]

Which worked.  I hope this was the right thing to do.


My bad there, I was slightly pressed for time and did not check if 
default cyrus documentation was sane in freebsd context - what you did 
was quite correct.



However, upon startup, I now see the following in all.log:

[SNIP]
I'm not sure if this feature is needed for reproducing the crash, 
so I
modified cyrus.conf and commented the line out, then restarted 
imapd,

which got me:


Yep, idled can be disabled as far as I'm aware, so nothing drastic 
there either.



Then for the final test:

testbox# cyradm
cyradm quit
testbox# cyradm localhost
Password:

Where I hit enter/blank, which got me:

Login disabled.
cyradm: cannot authenticate to server with  as root
testbox#

And no sign of a crash.

So what's next?


I forgot to check all.log.  It contains errors.  Hopefully someone 
will

know what to do about this:

Jul 16 04:03:50 testbox imap[1619]: executed
Jul 16 04:03:50 testbox imap[1619]: accepted connection
Jul 16 04:03:50 testbox imap[1619]: OTP unavailable because can't 
read/write key database /etc/opiekeys: Permission denied
Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox imap[1619]: 
OTP unavailable because can't read/write key database /etc/opiekeys: 
Permission denied
Jul 16 04:03:50 testbox perl: GSSAPI Error:  Miscellaneous failure 
(see text) (unknown mech-code 2 for mech unknown)
Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox perl: GSSAPI 
Error:  Miscellaneous failure (see text) (unknown mech-code 2 for 
mech unknown)

Jul 16 04:03:50 testbox perl: DIGEST-MD5 client step 2
Jul 16 04:04:00 testbox imap[1619]: badlogin: localhost [127.0.0.1] 
DIGEST-MD5 [SASL(-17): One time use of a plaintext password will 
enable requested mechanism for user: no secret in database]

Jul 16 04:04:03 testbox perl: NTLM client step 1
Jul 16 04:04:03 testbox imap[1619]: NTLM server step 1
Jul 16 04:04:03 testbox imap[1619]: client flags: 207
Jul 16 04:04:03 testbox perl: NTLM client step 2
Jul 16 04:04:03 testbox perl: No worthy mechs found
Jul 16 04:04:03 testbox kernel: Jul 16 04:04:03 testbox perl: No 
worthy mechs found


You can move the surplus mechs (libopie*, libntlm*) from 
/usr/local/lib/sasl2 to for example /usr/local/lib/sasl2/disabled


check that you have the following in /etc/rc.conf and restart 
saslauthd afterwards


saslauthd_enable=YES
saslauthd_flags=-a pam

-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

2010-07-16 Thread Jeremy Chadwick 
On Fri, Jul 16, 2010 at 02:33:17PM +0300, Reko Turja wrote:
 You can move the surplus mechs (libopie*, libntlm*) from
 /usr/local/lib/sasl2 to for example /usr/local/lib/sasl2/disabled

To deal with this in a more clean manner, I rebuilt
security/cyrus-sasl23 with the following OPTIONS unchecked:

OTP
NTLM

 check that you have the following in /etc/rc.conf and restart
 saslauthd afterwards
 
 saslauthd_enable=YES
 saslauthd_flags=-a pam

saslauthd isn't in use/installed on this system:

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

Same situation:

testbox# cyradm localhost
Password:
Login disabled.
cyradm: cannot authenticate to server with  as root

all.log:

Jul 16 05:13:19 testbox master[10873]: about to exec /usr/local/cyrus/bin/imapd
Jul 16 05:13:19 testbox imap[10873]: executed
Jul 16 05:13:19 testbox imap[10873]: accepted connection
Jul 16 05:13:19 testbox perl: GSSAPI Error:  Miscellaneous failure (see text) 
(unknown mech-code 2 for mech unknown)
Jul 16 05:13:19 testbox kernel: Jul 16 05:13:19 testbox perl: GSSAPI Error:  
Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown)
Jul 16 05:13:19 testbox perl: DIGEST-MD5 client step 2
Jul 16 05:13:20 testbox imap[10873]: badlogin: localhost [127.0.0.1] DIGEST-MD5 
[SASL(-17): One time use of a plaintext password will enable requested 
mechanism for user: no secret in database]
Jul 16 05:13:23 testbox perl: No worthy mechs found
Jul 16 05:13:23 testbox kernel: Jul 16 05:13:23 testbox perl: No worthy mechs 
found

It looks like authentication isn't working, probably because I haven't
added any users into the SASL authentication DB.  I believe saslauthd
can also solve this (allowing use of things like /etc/master.passwd
for authentication, as well as other frameworks), but it doesn't look
like it's required.

When I did make install for security/cyrus-sasl23, I saw this
message near the end:

You can use sasldb2 for authentication, to add users use:

saslpasswd2 -c username

So I tried doing exactly that:

testbox# saslpasswd2 -c root
Password:
Again (for verification):
testbox#

Now let's try cyradm again.  Note that at this point I *have not*
entered a password below:

testbox# cyradm localhost
Password:

I immediately see this in syslog:

Jul 16 05:19:47 testbox imap[10881]: accepted connection
Jul 16 05:19:47 testbox perl: GSSAPI Error:  Miscellaneous failure (see text) 
(unknown mech-code 2 for mech unknown)
Jul 16 05:19:47 testbox perl: DIGEST-MD5 client step 2

Now if I enter the correct password, I get a new prompt:

localhost

And syslog then shows:

Jul 16 05:21:06 testbox imap[10881]: IOERROR: opening /var/imap/user_deny.db: 
No such file or directory
Jul 16 05:21:06 testbox perl: DIGEST-MD5 client step 3
Jul 16 05:21:06 testbox imap[10881]: login: localhost [127.0.0.1] root 
DIGEST-MD5 User logged in
Jul 16 05:21:06 testbox imap[10881]: IOERROR: opening /var/imap/user_deny.db: 
No such file or directory

So it looks like SASL-wise things are functioning correctly, but GSSAPI
isn't in use (you can see from the error it spits out above).

I think we need the OP of the PR[1], Mikhail T., to chime in here with his
setup.

[1]: http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html

-- 
| 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

2010-07-16 Thread Reko Turja 
I think we need the OP of the PR[1], Mikhail T., to chime in here 
with his

setup.


While waiting, can you test the following: In the 
/usr/local/etc/imapd.conf file comment out


#sasl_pwcheck_method: saslauthd

and add below it:

sasl_mech_list: gssapi pam plain

-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

2010-07-16 Thread Jeremy Chadwick 
On Fri, Jul 16, 2010 at 03:58:04PM +0300, Reko Turja wrote:
 I think we need the OP of the PR[1], Mikhail T., to chime in here
 with his
 setup.
 
 While waiting, can you test the following: In the
 /usr/local/etc/imapd.conf file comment out
 
 #sasl_pwcheck_method: saslauthd
 
 and add below it:
 
 sasl_mech_list: gssapi pam plain

Thanks -- I did so + restarted imapd, and now we have:

testbox# cyradm localhost
Login disabled.
cyradm: cannot authenticate to server with  as root

Jul 16 06:46:02 testbox master[11087]: about to exec /usr/local/cyrus/bin/imapd
Jul 16 06:46:02 testbox imap[11087]: executed
Jul 16 06:46:02 testbox imap[11087]: accepted connection
Jul 16 06:46:02 testbox perl: GSSAPI Error:  Miscellaneous failure (see text) 
(unknown mech-code 2 for mech unknown)
Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: GSSAPI Error:  
Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown)
Jul 16 06:46:02 testbox perl: No worthy mechs found
Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: No worthy mechs 
found

-- 
| 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

2010-07-15 Thread Jeremy Chadwick 
On Thu, Jul 15, 2010 at 12:14:58AM +0300, Reko Turja wrote:
 I had similar issue with 8-RELEASE and cyrus-sasl2 with cyrus-saslauthd 
 linked against system kerberos.
 
 (uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1:
 Sat Jun 12 00:39:22 EEST 2010
 r...@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW  i386)
 
 The problem manifested itself with pretty much the same backtrace
 when using cyradm tool for administering cyrus mailboxes and due
 time constraints I solved my issue by removing all the gssapi
 plugin libs from /usr/local/lib/sasl2, so my solution isn't really
 applicable in your case.
 
 After building perl, cyrus-sasl2 and userland/kernel with debug symbols
 I was able to get the following backtrace.
 
 #0  free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889
 3889arena_dalloc(chunk-arena, chunk, ptr);
 [New Thread 286ae140 (LWP 100273)]
 (gdb) bt
 #0  free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889
 #1  0x2899ed32 in gss_release_buffer (minor_status=0xbfbfe4b8,
 buffer=0x280871cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41
 #2  0x2899e6e2 in _gss_mg_error (m=0x28a86480, maj=851968, min=2) at 
 /usr/src/lib/libgssapi/gss_display_status.c:240
 #3  0x2899afd9 in gss_init_sec_context (minor_status=0xbfbfe5a4, 
 initiator_cred_handle=0x0, context_handle=0x28630164,
target_name=0x2861b380, input_mech_type=0x0, req_flags=58, time_req=0, 
 input_chan_bindings=0x0, input_token=0x0,
actual_mech_type=0x0, output_token=0xbfbfe5a8, ret_flags=0xbfbfe594, 
 time_rec=0x0)
at /usr/src/lib/libgssapi/gss_init_sec_context.c:156
 #4  0x289936c9 in gssapi_client_mech_step (conn_context=0x28630160, 
 params=0x28a97080, serverin=0x0, serverinlen=0,
prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, 
 oparams=0x28a95860) at gssapi.c:1418
 #5  0x285810f6 in sasl_client_step (conn=0x28a95000, serverin=0x0,
 serverinlen=0, prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac,
clientoutlen=0xbfbfe8a8) at client.c:655
 #6  0x28580ef7 in sasl_client_start (conn=0x28a95000,
 mechlist=0x2861b360 GSSAPI DIGEST-MD5 CRAM-MD5 ,
 prompt_need=0xbfbfe8b0,
clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, mech=0xbfbfe8b8) at 
 client.c:603
 #7  0x2856a94c in imclient_authenticate () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so
 #8  0x28566f5e in XS_Cyrus__IMAP__authenticate () from
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so
 #9  0x281d8f30 in Perl_pp_entersub () at pp_hot.c:2888
 #10 0x281878bc in Perl_runops_debug () at dump.c:1968
 #11 0x280d80a9 in S_run_body (oldscope=1) at perl.c:2431
 #12 0x280d7535 in perl_run (my_perl=0x28601100) at perl.c:2349
 #13 0x08048930 in main (argc=6, argv=0xbfbfec44, env=0xbfbfec60) at 
 perlmain.c:117
 
 I'm complete GDB-idjit though so any help in getting usable information
 from the following trace would be appreciated - I have the dump etc.
 stored away for further digging of course.

The dump is only useful if it's used on that exact system it came from,
so don't rebuild any of the software/etc. until we get this figured out.

The code in question:

src/lib/libgssapi/gss_display_status.c

186 struct mg_thread_ctx {
187 gss_OID mech;
188 OM_uint32 maj_stat;
189 OM_uint32 min_stat;
190 gss_buffer_desc maj_error;
191 gss_buffer_desc min_error;
192 };
...
231 void
232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj, OM_uint32 min)
233 {
234 OM_uint32 major_status, minor_status;
235 OM_uint32 message_content;
236 struct mg_thread_ctx *mg;
237
238 mg = last_error_context;
239
240 gss_release_buffer(minor_status, mg-maj_error);
241 gss_release_buffer(minor_status, mg-min_error);

src/lib/libgssapi/gss_release_buffer.c

 34 OM_uint32
 35 gss_release_buffer(OM_uint32 *minor_status,
 36gss_buffer_t buffer)
 37 {
 38
 39 *minor_status = 0;
 40 if (buffer-value)
 41 free(buffer-value);

src/include/gssapi/gssapi.h

106 typedef struct gss_buffer_desc_struct {
107   size_t length;
108   void *value;
109 } gss_buffer_desc, *gss_buffer_t;

So I'm going to take a shot in the dark at this one, with some
supporting evidence.

It looks like gss_release_buffer.c:40 is improper/incomplete -- it's
only checking to see if the pointer is non-NULL, and then blindly calls
free().  It doesn't bother to check to see if buffer-length is
non-zero.

It seems gss_release_buffer() is basically mindless about what it frees
anyway, which is bad design given the complexity of this thing.  Well,
some MIT Kerberos dudes complained about it too, and solved it by adding
magic numbers to the structure so that you can tell what type of
buffer it is:

http://krbdev.mit.edu/rt/Ticket/Display.html?id=2145

The patch/code there is in no way shape or

Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386

2010-07-15 Thread Reko Turja 


--
From: Jeremy Chadwick free...@jdc.parodius.com
Sent: Thursday, July 15, 2010 7:22 PM
To: Reko Turja reko.tu...@liukuma.net
Cc: Henrik /KaarPoSoft hen...@kaarposoft.dk; 
freebsd-stable@freebsd.org
Subject: Re: openldap client GSSAPI authentication segfaults in 
fbsd8stablei386



That said, can you please execute the following in gdb and provide
the output?

(gdb) p/x gss_release_buffer.c::buffer-value
(gdb) p/x gss_release_buffer.c::buffer-length


Those gave syntax error, but going to frame 1 and printing the values 
gives the following:


(gdb) f 1
#1  0x2899ed12 in gss_release_buffer (minor_status=0xbfbfe4b8, 
buffer=0x280871cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41

41  free(buffer-value);
(gdb) p/x buffer-length
$1 = 0x0
(gdb) p/x gss_release_buffer.c::buffer-length
A syntax error in expression, near `::buffer-length'.
(gdb) p/x buffer-value
$2 = 0x280871c0

Hope this helps - definitely looks like the issue you are suspecting.

-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

2010-07-14 Thread Reko Turja 

I had similar issue with 8-RELEASE and cyrus-sasl2 with cyrus-saslauthd linked 
against system kerberos.

(uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat Jun 12 00:39:22 EEST 2010 
r...@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW  i386)


The problem manifested itself with pretty much the same backtrace when using cyradm tool for administering cyrus 
mailboxes and due time constraints I solved my issue by removing all the gssapi plugin libs from /usr/local/lib/sasl2, 
so my solution isn't really applicable in your case.


After building perl, cyrus-sasl2 and userland/kernel with debug symbols
I was able to get the following backtrace.

#0  free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889
3889arena_dalloc(chunk-arena, chunk, ptr);
[New Thread 286ae140 (LWP 100273)]
(gdb) bt
#0  free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889
#1  0x2899ed32 in gss_release_buffer (minor_status=0xbfbfe4b8, buffer=0x280871cc) at 
/usr/src/lib/libgssapi/gss_release_buffer.c:41

#2  0x2899e6e2 in _gss_mg_error (m=0x28a86480, maj=851968, min=2) at 
/usr/src/lib/libgssapi/gss_display_status.c:240
#3  0x2899afd9 in gss_init_sec_context (minor_status=0xbfbfe5a4, 
initiator_cred_handle=0x0, context_handle=0x28630164,
   target_name=0x2861b380, input_mech_type=0x0, req_flags=58, time_req=0, 
input_chan_bindings=0x0, input_token=0x0,
   actual_mech_type=0x0, output_token=0xbfbfe5a8, ret_flags=0xbfbfe594, 
time_rec=0x0)
   at /usr/src/lib/libgssapi/gss_init_sec_context.c:156
#4  0x289936c9 in gssapi_client_mech_step (conn_context=0x28630160, 
params=0x28a97080, serverin=0x0, serverinlen=0,
   prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, 
oparams=0x28a95860) at gssapi.c:1418
#5  0x285810f6 in sasl_client_step (conn=0x28a95000, serverin=0x0, serverinlen=0, prompt_need=0xbfbfe8b0, 
clientout=0xbfbfe8ac,

   clientoutlen=0xbfbfe8a8) at client.c:655
#6  0x28580ef7 in sasl_client_start (conn=0x28a95000, mechlist=0x2861b360 GSSAPI DIGEST-MD5 CRAM-MD5 , 
prompt_need=0xbfbfe8b0,

   clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, mech=0xbfbfe8b8) at 
client.c:603
#7  0x2856a94c in imclient_authenticate () from 
/usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so
#8  0x28566f5e in XS_Cyrus__IMAP__authenticate () from 
/usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so

#9  0x281d8f30 in Perl_pp_entersub () at pp_hot.c:2888
#10 0x281878bc in Perl_runops_debug () at dump.c:1968
#11 0x280d80a9 in S_run_body (oldscope=1) at perl.c:2431
#12 0x280d7535 in perl_run (my_perl=0x28601100) at perl.c:2349
#13 0x08048930 in main (argc=6, argv=0xbfbfec44, env=0xbfbfec60) at 
perlmain.c:117

I'm complete GDB-idjit though so any help in getting usable information
from the following trace would be appreciated - I have the dump etc.
stored away for further digging of course.

-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