ACI and subtrees interactions

[Emmanuel Lecharny <el...@gmail.com>]

  Hi,

I'm just checking the subentryInterceptor while trying to find the best 
way to fix the ACI handling when the server is stopped and restarted.

There is something really unpleasant in this interceptor : when adding a 
subtree, we do a search in the DIT to find all the entries part of the 
subtree, and each of them is modified to have the 
accessControlSubentries AT added, with a reference to the subentry.

If the server contains millions of enries, this is simply not an option.

The direct consequence is that anytime we add an ACI which span over a 
lot of entries, we wwill have a large number of modifications applied, 
and it's definitively a costly operation (moreover, I don't see how we 
can assure the atomicity of such an operation...)

We have to find a better way to determinate if an entry is part of a 
subtree than by modifying this entry.

Another annoying aspect is that when we evaluate an ACI, we have to get 
the subtree from the subEntry interceptor, because the associated cache 
is not global. This is not a good thing too. Caches must be handled 
globally by the DirectoryService instance, not by each interceptors.

Still a lot of work before we can release a production ready server, 
guys...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: ACI and subtrees interactions

[Emmanuel Lecharny <el...@apache.org>]

>
> The direct consequence is that anytime we add an ACI which span over a
>> lot of entries, we wwill have a large number of modifications applied,
>> and it's definitively a costly operation (moreover, I don't see how we
>> can assure the atomicity of such an operation...)
>>
>
> This is one of the reasons we still don't have proper subentry support in
> OpenLDAP. I think to do it in a sane fashion you want all of these
> XXXsubEntry attributes to be generated dynamically. But, if you have a lot
> of subentry specifications applying to a tree, you'll pay for it in search
> performance because you have to evaluate all of them each time you reference
> an entry. That leaves the caching approach that we took for subtree rename.
>

I'm not sure that, due to the complexity of subtree definition, we will have
'a lot' >> a few tens of subtrees...

In this case, the cost of generating those attributeTypes dynamically can be
mitigated.

Of course you will always find pathological admins defining hundreds or even
thousands of subtrees (I have in mind some tools which would automatically
generates those guys, ot a huan being, but you never know ;), but in this
case, well, I woud ask them to switch to OpenLdap ;)

More seriously, checking in an entry found during a search is a part of some
subtree is just adding one filter and as it will be executed in emory, it
should not overload the server. The time penalty to process this information
is obvious, but we can bear with it. We are not talking about order of
magnitude here, not even a 2 times factor, it should be some extra
percentage.

Anyway, I can't give numbers right now as we first have to get the subtree
creation handled correctly first. The current implementation works, but it's
obviously more a proof of concept than a realistic iplemntation.

Thanks Howard !

>
> --
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/
>



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: ACI and subtrees interactions

[Howard Chu <hy...@symas.com>]

Emmanuel Lecharny wrote:
>    Hi,
>
> I'm just checking the subentryInterceptor while trying to find the best
> way to fix the ACI handling when the server is stopped and restarted.
>
> There is something really unpleasant in this interceptor : when adding a
> subtree, we do a search in the DIT to find all the entries part of the
> subtree, and each of them is modified to have the
> accessControlSubentries AT added, with a reference to the subentry.
>
> If the server contains millions of enries, this is simply not an option.
>
> The direct consequence is that anytime we add an ACI which span over a
> lot of entries, we wwill have a large number of modifications applied,
> and it's definitively a costly operation (moreover, I don't see how we
> can assure the atomicity of such an operation...)

This is one of the reasons we still don't have proper subentry support in 
OpenLDAP. I think to do it in a sane fashion you want all of these XXXsubEntry 
attributes to be generated dynamically. But, if you have a lot of subentry 
specifications applying to a tree, you'll pay for it in search performance 
because you have to evaluate all of them each time you reference an entry. 
That leaves the caching approach that we took for subtree rename.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/