On Mon, 2015-04-20 at 08:53 +0200, Lukas Slebodnik wrote:
Nack. I'd rather we fixed the root of this problem. I did some digging
this afternoon and tracked the issue back to ad_gpo.c line 3499 (in
current master). If we get back a NULL result or num_results == 0,
then we just skip over this item in the list and start processing the
next one. Unfortunately, that leaves an item in the candidate_gpos
list that was never properly constructed.
Under what circumstances can the secinfo_dacl search return success
but with zero results? Is there a bug or a race here (such as the AD
server has updated the GPO since we got the list of candidate GPOs?).
How best to handle this?
With your patch here, it looks like we're assuming that it's okay to
just skip over this GPO. If that's the case, then what we really need
to be doing in ad_gpo_get_gpo_attrs_step() is to mark the gp_gpo as
being invalid and then after we've gone through them all, shrink the
array, removing all of the invalid entries. This will be more future-
proof, as it's not just the gpo_sd that is uninitialized here. Every
member of this gp_gpo is NULL except for the DN.
If it's *not* okay that we've gotten no results for this lookup (such
as in the race case; we don't want to be skipping over a GPO that
might properly be denying users), we may need to restart processing at
least a couple times to try to avoid the race and go offline if we
can't complete the processing (so we at least stick to our cached
rules).