[SSSD] [PATCH] Last USN patches

Jan Zelený jzeleny at redhat.com
Thu Apr 28 06:07:29 UTC 2011


> On Wed, 2011-04-27 at 17:45 +0200, Jakub Hrozek wrote:
> > On 04/27/2011 03:30 PM, Stephen Gallagher wrote:
> > > 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.
> > 
> > Ack
> 
> I'm going to hold off pushing this until I get buy-in from Jan.

Thanks for catching this.

One question though: did you test reconnection to the same server with reset 
USN? I'm sure it will work in terms of refreshing the local database, I'm just 
not entirely certain that the srv_opts->last_usn will be set to current value 
later in the code (which would mean the next reconnection to the same server 
wouldn't start refreshing the data). If the test passes, consider the patch 
Acked.

I can test this scenario (reconnecting to the same server at least twice, both 
times with USN lower than registered in SSSD) myself, but not until this 
evening, I have busy schedule during the day.

Thanks
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110428/609ebe5c/attachment.sig>


More information about the sssd-devel mailing list