[SSSD] SIGSEGV in sssd_be using ldap_init_fd

John Hodrien J.H.Hodrien at leeds.ac.uk
Fri Jul 29 13:15:06 UTC 2011


On Fri, 29 Jul 2011, Stephen Gallagher wrote:

> On Fri, 2011-07-29 at 14:09 +0200, Jan Zelený wrote:
>>> 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 think we don't stop you from setting ldap_id_use_start_tls, but it's
> only going to introduce unnecessary slowdown (encrypting everything
> twice).

It doesn't work if I enable both.  I figured it wasn't necessary anyway as
there's no need, but thought I'd mention it.

(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [objectClass]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [sAMAccountName]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [userPassword]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [msSFU30UidNumber]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [primaryGroupID]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [displayName]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [msSFU30HomeDirectory]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [msSFU30LoginShell]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [userPrincipalName]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [cn]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [memberOf]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [nsUniqueId]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [modifyTimestamp]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowLastChange]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowMin]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowMax]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowWarning]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowInactive]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowExpire]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowFlag]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [krbLastPwdChange]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [krbPasswordExpiration]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [pwdAttribute]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [authorizedService]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [accountExpires]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [userAccountControl]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting attrs: [nsAccountLock]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (8): ldap_search_ext called, msgid = 6
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_id_op_connect_done] (9): caching successful connection after 1 notifies
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [be_run_online_cb] (3): Going online. Running callbacks.
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x2098090], connected[1], ops[0x1ff00e0], ldap[0x2096f00]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result gave -1, something bad happend!
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_handle_release] (8): Trace: sh[0x2098090], connected[1], ops[0x1ff00e0], ldap[0x2096f00], destructor_lock[0], release_memory[0]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [remove_connection_callback] (9): Successfully removed connection callback.
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_id_op_done] (5): communication error on cached connection, moving to next server

> John, you should be aware of https://fedorahosted.org/sssd/ticket/783
> though. Currently we don't support AD's standards-violating RANGE
> extension, so we're limited to the first 1500 (AD 2008) or 1000 (AD
> 2003) users listed in a group.

AD standards violating?  You do surprise me...  ;)

To be honest it was easy enough to trip up nss_ldap and nscd with this sort of
stuff too, so it shouldn't be something we depend on.

> So if you have any exceedingly large groups, you're likely to hit this.

This is only about *flat* groups though I assume?  Largest group I can find
that I use is <1500 flat members (we'll be pure 2008 by the time I use this).

I'm thinking sssd likely to crawl into a hole at some point anyway, but the
caching's a whole lot more sane, so I'm hoping it'll plod along more
successfully than nss_ldap/nscd.

jh


More information about the sssd-devel mailing list