#1950 segfault while processing ASQ request
Closed: Fixed None Opened 5 years ago by jhrozek.

A user on the #sssd channel hit a segfault when processing an ASQ dereference request. This may or may not be the same issue as #1894, so they should be investigated together.

The backtrace was:

Program received signal SIGSEGV, Segmentation fault.
sdap_asq_search_parse_entry (sh=0x85feb0, msg=0xdd74e0,
    pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:1967
1967            for (i = 0; vals[i]; i++) {
Missing separate debuginfos, use: debuginfo-install nss-softokn-3.12.9-11.el6.x86_64 sqlite-3.6.20-1.el6.x86_64
(gdb) bt
#0  sdap_asq_search_parse_entry (sh=0x85feb0, msg=0xdd74e0,
    pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:1967
#1  0x00007fc8a4328d91 in sdap_get_generic_ext_done (op=<value optimized out>,
    reply=0xdd74e0, error=0, pvt=<value optimized out>)
    at src/providers/ldap/sdap_async.c:1347
#2  0x00007fc8a432eb1f in sdap_process_message (ev=<value optimized out>,
    pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:366
#3  sdap_process_result (ev=<value optimized out>, pvt=<value optimized out>)
    at src/providers/ldap/sdap_async.c:209
#4  0x00000034caa07bd9 in tevent_common_loop_timer_delay ()
   from /usr/lib64/libtevent.so.0
#5  0x00000034caa072ab in ?? () from /usr/lib64/libtevent.so.0
#6  0x00000034caa038f0 in _tevent_loop_once () from /usr/lib64/libtevent.so.0
#7  0x00000034caa0395b in tevent_common_loop_wait ()
   from /usr/lib64/libtevent.so.0
#8  0x00007fc8ac8a38d3 in server_loop (main_ctx=0x82b6d0)
    at src/util/server.c:602
#9  0x0000000000413626 in main (argc=<value optimized out>,
    argv=<value optimized out>) at src/providers/data_provider_be.c:2771

Debug log from the above backtrace (sanitized with [...]). Interesting part is probably around line 53200.
debug-sanitized.gz

Fields changed

owner: somebody => lslebodn
patch: 0 => 1

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.10 beta
rhbz: => todo

resolution: => fixed
status: new => closed

The fix only adds a NULL check, doesn't solve the issue of why was the objectclass missing. But hopefully the new debug message added with the commit would tell us which entry was misbehaving and we'll be able to inspect it in LDAP.

No RHEL clone is needed, this was not reported by a RHEL customer and we never saw the problem again.

rhbz: todo => 0

Hello guys,

I faced the "objectclass missing" message. Isn't this one?

'Unknown entry type, no objectClass found for DN'

So, the problem happens when loading the groups for a user. For example:

LDAP server is AD 2k8

LDAP is connected with anonymous user (I guess this will happen even if authenticated)

user1 is member of group1, group2, group3

user2 is member of group2

When user1 logs in, sssd loads all its groups. When a group is loaded, all its members are also checked (looking for nested groups?). In this case, when loading group2, sssd looks for user2. If the current ldap conn user (anonymous in this case) does not have permission to read user2 attributes, no objectclass is returned. SSSD fails with the cited message and group expansion stops. For SSSD, user1 only belongs to group1 as group2 failed and group3 didn't even had the chance to be loaded. The nice behavior would be to skip user2 and go on.

It is very easy to reproduce. Just add a user to a group in a AD and remove in Security tab all permission to the used "ldap conn user".

I'm currently using OpenSuSE Leap package (1.11.5.1). Is there a patch on master that fixes this issue?

_comment0: Hello guys,

I faced the "objectclass missing" message. Isn't this one?

'Unknown entry type, no objectClass found for DN'

So, the problem happens when loading the groups for a user. For example:

LDAP server is AD 2k8
LDAP is connected with anonymous user (I guess this will happen even if authenticated)

user1 is member of group1, group2, group3
user2 is member of group2

When user1 logs in, sssd loads all its groups. When a group is loaded, all its members are also checked (looking for nested groups?). In this case, when loading group2, sssd looks for user2. If the current ldap conn user (anonymous in this case) does not have permission to read user2 attributes, no objectclass is returned. SSSD fails with the cited message and group expansion stops. For SSSD, user1 only belongs to group1 as group2 failed and group3 didn't even had the chance to be loaded. The nice behavior would be to skip user2 and go on.

It is very easy to reproduce. Just add a user to a group in a AD and remove in Security tab all permission to the used "ldap conn user".

I'm currently using OpenSuSE Leap package (1.11.5.1). Is there a patch on master that fixes this issue? => 1448659259096418
changelog: =>
mark: => 0
sensitive: => 0

Replying to [comment:6 luizluca]:

It is very easy to reproduce. Just add a user to a group in a AD and remove in Security tab all permission to the used "ldap conn user".

I'm currently using OpenSuSE Leap package (1.11.5.1). Is there a patch on master that fixes this issue?

The patch is in the comment:3 but it it is already in sssd >= 1.10.0.

BTW I asked openSUSE maintainer to upgrade to latest sssd-1.11 or sssd-1.12 because 1.11.5.1 is buggy.
Unfortunately, the request was revoked https://build.opensuse.org/request/show/337995

I would recommend you to test with newer version (1.12.5 or 1.13.2). You might use repositories from openSUSE Build Service https://build.opensuse.org/package/show/network:ldap/sssd

zypper addrepo -f http://download.opensuse.org/repositories/network:/ldap/openSUSE_Leap_42.1/network:ldap.repo

Metadata Update from @jhrozek:
- Issue assigned to lslebodn
- Issue set to the milestone: SSSD 1.10 beta

2 years ago

Login to comment on this ticket.

Metadata