[SSSD] [PATCH] Pass client context to sss_dp_get_account_send

Jan Zelený jzeleny at redhat.com
Mon Dec 19 12:23:20 UTC 2011


> > My recent fix "DP: Remove processed callbacks" uncovered another bug
> > which needs immediate attention - any NSS operation currently aborts in
> > git HEAD. That's my fault, I only tested my previous fix with cached user
> > data inside the PAM responder where the new bug does not hit. Sorry for
> > that.
> > 
> > The problem is memory hierarchy. When user data update is requested
> > from check_cache(), the sss_dp_callback structures are created on
> > sss_domain_context. However, when the callback is called, it goes all the
> > way into nss_cmd_getpw_send_reply() where the command context is freed,
> > freeing also sss_domain_context and the sss_dp_callback data. That's a
> > problem because we are still looping over the callback data.
> > 
> > Attached is a patch that changes the memory context for the
> > sss_dp_callback to the client context so it's kept even when the command
> > finishes. The callbacks are freed in the sss_dp_get_account_int_done()
> > function after the callback finishes so we're not keeping them for long.
> > 
> > The other solution I was thinking about was to not call the callbacks
> > directly, but only schedule them with tevent_schedule_immediate() so
> > that we can safely loop over all the callbacks, free the sdp_req and
> > then let the clients do whatever they need to.
> 
> Ack, pushed to master
> 
> Jan

Just a note: I'm not sure the suggested solution with 
tevent_schedule_immediate() would solve anything on its own. I didn't go 
through the code thoroughly, but I think there might be still a problem when a 
callback frees the dctx. Other callbacks would be freed anyway in that case 
wouldn't they?

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/20111219/f7539933/attachment.sig>


More information about the sssd-devel mailing list