[PATCH] Fix enumeration for IPA providers

[Jakub Hrozek]

Hi,

I found out that the IPA provider segfaults when it receives an
enumeration request. The first patch gets rid of the segfault, but there
would still be an error in the IPA provider is it would expect the
be_req contents to be usable for cache search. The second patch
shortcuts the enumeration request completely.

I even wonder if it was possible to shortcut the enumeration requests
sooner in the Data Provider and avoid sending them to the back ends
completely? Any downsides to this (except a possible 3rd party backend
that might allow an enumeration request on demand) ?

Finally, enumeration with IPA backend and ID views don't work at all,
but I wouldn't waste time with this at the moment -- just make sure that
we don't reqress.

[Jakub Hrozek]

On Mon, May 25, 2015 at 11:04:27AM +0200, Jakub Hrozek wrote:
> Hi,
>
> I found out that the IPA provider segfaults when it receives an
> enumeration request. The first patch gets rid of the segfault, but there
> would still be an error in the IPA provider is it would expect the
> be_req contents to be usable for cache search. The second patch
> shortcuts the enumeration request completely.
>
> I even wonder if it was possible to shortcut the enumeration requests
> sooner in the Data Provider and avoid sending them to the back ends
> completely? Any downsides to this (except a possible 3rd party backend
> that might allow an enumeration request on demand) ?
>
> Finally, enumeration with IPA backend and ID views don't work at all,
> but I wouldn't waste time with this at the moment -- just make sure that
> we don't reqress.

Bump..

[Sumit Bose]

On Sun, May 31, 2015 at 07:50:10PM +0200, Jakub Hrozek wrote:
> On Mon, May 25, 2015 at 11:04:27AM +0200, Jakub Hrozek wrote:
> > Hi,
> >
> > I found out that the IPA provider segfaults when it receives an
> > enumeration request. The first patch gets rid of the segfault, but there
> > would still be an error in the IPA provider is it would expect the
> > be_req contents to be usable for cache search. The second patch
> > shortcuts the enumeration request completely.
> >
> > I even wonder if it was possible to shortcut the enumeration requests
> > sooner in the Data Provider and avoid sending them to the back ends
> > completely? Any downsides to this (except a possible 3rd party backend
> > that might allow an enumeration request on demand) ?
> >
> > Finally, enumeration with IPA backend and ID views don't work at all,
> > but I wouldn't waste time with this at the moment -- just make sure that
> > we don't reqress.
>
> Bump..

sorry for the delay. I wasn't able to reproduce the segfault even with
MALLOC_PERTURB_ but the changes in the first patch are a good idea
anyways.

Catching the enumeration requests as early as possible is a good idea as
well. We might even think about catching them already in the responders?
Maybe we can introduce some kind of feature map of the backends which
are given to the responder when connecting to the backend. Then the
responder can decide it it make sense to send the request to the backend
or just return data from the cache?

Nevertheless I didn't found and issue with the patches neither does
CI (http://sssd-ci.duckdns.org/logs/job/16/49/summary.html) so ACK.

bye,
Sumit
> sssd-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Jakub Hrozek]

On Mon, Jun 01, 2015 at 11:35:02AM +0200, Sumit Bose wrote:
> On Sun, May 31, 2015 at 07:50:10PM +0200, Jakub Hrozek wrote:
> > On Mon, May 25, 2015 at 11:04:27AM +0200, Jakub Hrozek wrote:
> > > Hi,
> > >
> > > I found out that the IPA provider segfaults when it receives an
> > > enumeration request. The first patch gets rid of the segfault, but there
> > > would still be an error in the IPA provider is it would expect the
> > > be_req contents to be usable for cache search. The second patch
> > > shortcuts the enumeration request completely.
> > >
> > > I even wonder if it was possible to shortcut the enumeration requests
> > > sooner in the Data Provider and avoid sending them to the back ends
> > > completely? Any downsides to this (except a possible 3rd party backend
> > > that might allow an enumeration request on demand) ?
> > >
> > > Finally, enumeration with IPA backend and ID views don't work at all,
> > > but I wouldn't waste time with this at the moment -- just make sure that
> > > we don't reqress.
> >
> > Bump..
>
> sorry for the delay. I wasn't able to reproduce the segfault even with
> MALLOC_PERTURB_ but the changes in the first patch are a good idea
> anyways.
>
> Catching the enumeration requests as early as possible is a good idea as
> well. We might even think about catching them already in the responders?
> Maybe we can introduce some kind of feature map of the backends which
> are given to the responder when connecting to the backend. Then the
> responder can decide it it make sense to send the request to the backend
> or just return data from the cache?
>
> Nevertheless I didn't found and issue with the patches neither does
> CI (http://sssd-ci.duckdns.org/logs/job/16/49/summary.html) so ACK.

Thanks for the review. Pushed upstream:

master:
    40bc389bc79bc41429b5a92d5ce75955f8eefaf5
    d9296ba018228ac6a19f710b8bb9044c4ea9ab5b 
sssd-1-12:
    62e595a57440786af4bc7e7d05596dc6756e0e4d
    2dfb4ed5a36a7be6bcde60e042811b81e83c4850

I also filed a ticket https://fedorahosted.org/sssd/ticket/2664 to take
another look at the enumeration requests.