On 6/15/11 2:25 AM, Alex Karasulu wrote:
On Mon, Jun 13, 2011 at 5:39 PM, Emmanuel Lecharny<[email protected]> wrote:
Alias cycle detection
---------------------
There is an unsolved question about how we should detect Alias cycles. Right
now, we check for cycles *before* they are created. The alternative would be
to stop any search that could lead to an infinite loop.
That would slow down reads. The best is to stop this from happening
with write operations: meaning doing the computation to detect and
prevent the cycle then and there instead of exhausting the search
process to deal with such wicked constructs.
If we do that, then we won't be able to pass VSLDAP tests. And the
slowdown will be *very* minimal : we just need an additional filter
which checks if the read entry is an alias (if not, we just do nothing),
and if it's an alias, we put its DN in a Set of DNs in the
SearchRequestContect.
The problem with the first approach is that we can't anymore pass the VSLDAP
tests. It's a major burden. Also most of the current servers support this
feature.
Is there a VSLDAP test that allows for alias cycle creation? If so we
should be able to bring this up with the Open Group. This is
definitely a gray area in the protocol but it makes little sense to
create alias cycles. Alias chaining on the other hand is a different
story.
Alias creation is not the server business. The user (or admin) is
responsible for such mistakes. Sadly, it *will* happen, and we must
forbid this. Right now, we detect a cycle the hard way, using indexes,
and I'm pretty sure that in complex cases where the cycle is far away
from the base search, it might take a while to detect it.
True, this is a gray area, because nowhere in the RFCs it is said that
Alias cycle are forbidden, and we must protect the server from such
behavior.
So let me ask once again since I know little about the VSLDAP tests:
do they allow alias chaining or alias loops? The two would be
different.
Alias chaining is definitively accepted.
Now, we also have some JIRAs that are a direct consequence of what we
have coded in the server atm :
https://issues.apache.org/jira/browse/DIRSERVER-803
And this is a VSLDAP Standard compliance test.
I will continue my experiments on the Filter approach, it's almost done
(I was surprised how easy it was to implement a cycle detection this
way), then we can compare this algorithm with another where we forbid
the cycle creation when adding a new alias.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
