[PATCH] Remove incorrect private variable
by Stephen Gallagher
This caused no ill effects, since it wasn't used in the callback.
However, it is a layering violation (especially since req is freed
in the callback)
12 years, 8 months
[PATCH] Wrong paramater to sysdb_attrs_add_uint32
by Jakub Hrozek
While reviewing Jan's sysdb patches I noticed that a call to
sysdb_attrs_add_uint32() I added recently is wrong.
The reason the code worked and the compiler did not complain was simple
- there's only one place that calls sdap_store_group_with_gid() and it
passes group_attrs for mem_ctx. If we ever reused
sdap_store_group_with_gid() with a different memory context it would
probably crash and burn.
Sorry about the inconvenience.
12 years, 8 months
[PATCH] Fix FD leak in pam_sss.so
by Simo Sorce
Attached patch that makes sure we alays close the socket on modeule
unloading.
It is defined in common.c so all clients that use that file get it, so
nss_sss.so has it as well.
Ticket #942
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12 years, 8 months
Re: [SSSD] SIGSEGV in sssd_be using ldap_init_fd
by Jan Zelený
> Jan Zelený wrote:
> > Yes, in recent versions you should have something like
> >
> > libnss3.so()(64bit)
>
> Just to confirm, this all now works perfectly and either GSSAPI or TLS.
> Am I right in assuming they are mutually exclusive?
Yes, they should be. However I'm not entirely sure if they are made mutually
exclusive in the code. We shall verify this.
> I'm switching to sssd to bind to an AD domain with >100k user objects
> and nearly 200k groups. sssd seems to be making a really good stab at
> coping with that, in a way that an unmodified nss_ldap/nscd simply
> couldn't. To be honest, that's pretty remarkable.
Thanks, we're always happy to hear that.
> Many thanks for your help with this, it really is appreciated.
>
> jh
Jan
12 years, 8 months
Re: [SSSD] SIGSEGV in sssd_be using ldap_init_fd
by Jan Zelený
> Jan Zelený wrote:
> > I suspect this to be the source of your problem. This is really archaic
> > version of openldap when used with SSSD. There have been huge changes in
> > libldap, more specifically it stopped using openssl as its backend and it
> > is now utilizing Mozilla NSS instead. Also many other TLS-related fixes
> > have been made in recent versions.
> >
> > Please try to use newer libldap, I believe, most recent in RHEL is
> > 2.4.23.
>
> Right, thanks for this. I'm just rebuilding that now and will let you
> know the results. CentOS are rather behind at the moment, and I hadn't
> caught the requirement for a more recent OpenLDAP from the Fedora src.rpm.
>
> > Just to be sure, you can run rpm -q --requires openldap and see if
> > openssl is there somewhere (there should be none).
>
> libssl.so.10()(64bit)
> libcrypto.so.10()(64bit)
>
> So I'm guessing that's wrong and old then.
>
> jh
Yes, in recent versions you should have something like
libnss3.so()(64bit)
Jan
12 years, 8 months
SIGSEGV in sssd_be using ldap_init_fd
by John Hodrien
I've looked at this, but can't see the wood for the trees.
Starting from 1.59 I can't use GSSAPI or TLS with LDAP. I've tried all
versions up to current git and I get the same basic result.
Undefining HAVE_LDAP_INIT_FD by editing the ldap.m4 to remove the test returns
it to life. Equally, not using TLS or GSSAPI works.
This is pointed at an Active Directory domain, using a machine credential for
the authentication.
Here's a stack trace from sssd_be aginst the current git HEAD
(d6354aa46716751a41ddab86bc64c1c7c218c5cc) when using GSSAPI:
Program received signal SIGSEGV, Segmentation fault.
0x0000003107e13f7f in ldap_int_sasl_bind () from /usr/lib64/libldap-2.4.so.2
(gdb) bt
#0 0x0000003107e13f7f in ldap_int_sasl_bind () from /usr/lib64/libldap-2.4.so.2
#1 0x0000003107e1665f in ldap_sasl_interactive_bind_s () from /usr/lib64/libldap-2.4.so.2
#2 0x00007f550c9a4ed1 in sasl_bind_send (memctx=0x1df9080, ev=0x1dca410, sh=0x1df6b10,
sasl_mech=0x1de71d0 "gssapi", sasl_user=0x1de8800 "SCSJHTEST1$", sasl_cred=0x0)
at src/providers/ldap/sdap_async_connection.c:650
#3 0x00007f550c9a6264 in sdap_auth_send (memctx=0x1e00d10, ev=0x1dca410, sh=0x1df6b10,
sasl_mech=0x1de71d0 "gssapi", sasl_user=0x1de8800 "SCSJHTEST1$", user_dn=0x0,
authtok_type=0x1de95f0 "password", authtok=...) at src/providers/ldap/sdap_async_connection.c:996
#4 0x00007f550c9a766a in sdap_cli_auth_step (req=0x1e00040) at src/providers/ldap/sdap_async_connection.c:1439
#5 0x00007f550c9a7532 in sdap_cli_kinit_done (subreq=0x0) at src/providers/ldap/sdap_async_connection.c:1430
#6 0x00007f550c9a5d9b in sdap_kinit_done (subreq=0x0) at src/providers/ldap/sdap_async_connection.c:904
#7 0x00007f550c9adc6c in sdap_get_tgt_done (subreq=0x0) at src/providers/ldap/sdap_child_helpers.c:376
#8 0x00007f550c96a469 in read_pipe_handler (ev=0x1dca410, fde=0x1df9bf0, flags=1, pvt=0x1df8f10)
at src/providers/child_common.c:250
#9 0x00007f5512cf0456 in epoll_event_loop (ev=<value optimized out>, location=<value optimized out>)
at tevent_standard.c:309
#10 std_event_loop_once (ev=<value optimized out>, location=<value optimized out>) at tevent_standard.c:544
#11 0x00007f5512ced6d0 in _tevent_loop_once (ev=0x1dca410, location=0x43e2e7 "src/util/server.c:550")
at tevent.c:490
#12 0x00007f5512ced73b in tevent_common_loop_wait (ev=0x1dca410, location=0x43e2e7 "src/util/server.c:550")
at tevent.c:591
#13 0x000000000043319c in server_loop (main_ctx=0x1dcb580) at src/util/server.c:550
#14 0x000000000040e0fd in main (argc=4, argv=0x7fffed680768) at src/providers/data_provider_be.c:1254
And the same using TLS but a username/password:
Program received signal SIGSEGV, Segmentation fault.
0x0000003107e31ac4 in ldap_int_tls_start () from /usr/lib64/libldap-2.4.so.2
(gdb) bt
#0 0x0000003107e31ac4 in ldap_int_tls_start () from /usr/lib64/libldap-2.4.so.2
#1 0x00007f329199a4b9 in sdap_connect_done (op=0xf6a690, reply=0xf6b5a0, error=0, pvt=0xf6a170)
at src/providers/ldap/sdap_async_connection.c:351
#2 0x00007f329197d34a in sdap_process_message (ev=0xf3e410, sh=0xf6a980, msg=0xf6a5b0)
at src/providers/ldap/sdap_async.c:364
#3 0x00007f329197cc17 in sdap_process_result (ev=0xf3e410, pvt=0xf6a980) at src/providers/ldap/sdap_async.c:207
#4 0x00007f329197c67e in sdap_ldap_result (ev=0xf3e410, fde=0xf6a550, flags=1, pvt=0xf6a980)
at src/providers/ldap/sdap_async.c:152
#5 0x00007f3297ce8456 in epoll_event_loop (ev=<value optimized out>, location=<value optimized out>)
at tevent_standard.c:309
#6 std_event_loop_once (ev=<value optimized out>, location=<value optimized out>) at tevent_standard.c:544
#7 0x00007f3297ce56d0 in _tevent_loop_once (ev=0xf3e410, location=0x43e2e7 "src/util/server.c:550")
at tevent.c:490
#8 0x00007f3297ce573b in tevent_common_loop_wait (ev=0xf3e410, location=0x43e2e7 "src/util/server.c:550")
at tevent.c:591
#9 0x000000000043319c in server_loop (main_ctx=0xf3f580) at src/util/server.c:550
#10 0x000000000040e0fd in main (argc=4, argv=0x7fff0cf385d8) at src/providers/data_provider_be.c:1254
Thanks,
jh
12 years, 8 months