[SSSD] [PATCH] Last USN patches

Stephen Gallagher sgallagh at redhat.com
Wed Apr 27 13:30:33 UTC 2011


On Tue, 2011-04-19 at 14:57 -0400, Stephen Gallagher wrote:
> On Tue, 2011-04-12 at 12:33 +0200, Jan Zelený wrote:
> > Can someone please take a look at the patch and ack that all issues discovered 
> > by Simo have been corrected?
> > 
> > Also note that in the original email there is another patch, which hasn't been 
> > reviewed yet.
> 
> Ack to both patches and pushed to master.


Unfortunately, I've now discovered several issues with this patch (too
late).

First, it causes a crash if SSSD started up in offline mode (e.g.
disconnected laptop) and then goes online (e.g. VPN).

#0  0x00007fec7adddd28 in sdap_check_online_done (req=0x0)
at ../src/providers/ldap/ldap_id.c:729
#1  0x00007fec7ae0f3e1 in sdap_cli_auth_done (subreq=0x0)
at ../src/providers/ldap/sdap_async_connection.c:1430
#2  0x00007fec7ae0e207 in sdap_auth_done (subreq=0x1ea9570)
at ../src/providers/ldap/sdap_async_connection.c:1007
#3  0x00007fec7ae0c8a9 in simple_bind_done (op=0x1ea9880,
reply=0x1ea97f0, error=0, pvt=0x1ea9570)
at ../src/providers/ldap/sdap_async_connection.c:540
#4  0x00007fec7adf4aa9 in sdap_process_message (ev=0x1e74470,
sh=0x1eb2c70, msg=0x1eb33e0) at ../src/providers/ldap/sdap_async.c:364
#5  0x00007fec7adf4363 in sdap_process_result (ev=0x1e74470,
pvt=0x1eb2c70) at ../src/providers/ldap/sdap_async.c:207
#6  0x00007fec7adf3db6 in sdap_ldap_result (ev=0x1e74470, fde=0x1eb3140,
flags=1, pvt=0x1eb2c70) at ../src/providers/ldap/sdap_async.c:152
#7  0x000000389ee05d57 in ?? () from /usr/lib64/libtevent.so.0
#8  0x000000389ee035b0 in _tevent_loop_once ()
from /usr/lib64/libtevent.so.0
#9  0x000000389ee0373b in tevent_common_loop_wait ()
from /usr/lib64/libtevent.so.0
#10 0x000000000043d41f in server_loop (main_ctx=0x1e755e0)
at ../src/util/server.c:526
#11 0x000000000040f8d2 in main (argc=6, argv=0x7fffbb9c67a8)
at ../src/providers/data_provider_be.c:1284


The problem is that ctx->srv_opts is NULL here (since we've never made a
connection to the server before this).

While I was investigating this, I noticed something else as well. This
entire IF block is completely useless as written. In the IF block, you
set ctx->srv_opts attributes, but then immediately after this block, you
replace the contents of ctx->srv_opts with the returned srv_opts from
sdap_cli_connect_recv()

My guess here is that the assignments in the IF block were supposed to
be setting srv_opts instead of ctx->srv_opts. The only part that
confuses me is where you're setting ctx->srv_opts->last_usn to
srv_opts->last_usn. I thought we had covered before that if the value
of srv_opts->last_usn was ever lower than the stored value, we MUST set
it to zero. This is because we know that the USN values are not in line
with the ones we have stored, so we have to do a full update to be
safe.

I'm attaching a patch that I think will resolve the issue (though I
can't test it as I don't have access to a server with USN values). At
the very least, it resolves the crash above for me.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-crash-bug-in-lastUSN-processing.patch
Type: text/x-patch
Size: 1702 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110427/8292309e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110427/8292309e/attachment.sig>


More information about the sssd-devel mailing list