Re: aliased bases

[Will Ballantyne <Will.Ballantyne@gems1.gov.bc.ca>]

Robert Streich wrote:

> I took a slightly different approach. I didn't want to have to touch
> every call to dn2entry() in order to propagate the deref option, I let
> dn2entry() fail, then check to see if the "matched" string is an alias.
> If it is, I resolve it (traversing a chain if necessary), then swap
> out the DN of the target entry with the "matched" portion of the
> original entry, then retrieve the original entry with the new DN.
> This way I only have to change the parameter list of and calls to
> base_candidates(), onelevel_candidates(), and subtree_candidates().
> This also makdes it easier to apply the right logic with the deref
> parameters. For example, in base_candidates(), you only need to test
> for "finding" and "always" since "searching" doesn't apply here.

Perhaps I missed something in your description, but it seems to me this does not work
for all cases.  The search method uses dn2id when there is a filter present, then
id2entry.   It does not use dn2entry for parts other than the search root. If you
search for an entry based on some filter and the alias object is returned, the alias
will not be dereferenced.

I think the parts we have done are complementary though.  What you describe seems to be
the part that dereferences information from the base when the base fails, the part
I have done dereferences when the alias is a candidate.

> Anyway, the last step is traversing the aliases below the base. It
> looks to me like the search routines fetch all entries that match the
> filter and then sort out the ones that apply given the scoping parameters.
> If this is the case, then it seems that the thing to do is to fetch
> all of the aliases, sort through the paths to get only those that are
> applicable, then test the scope of the returned candidates against a
> list of paths rather than just the original base.

Yes, that is how they work.  I am unsure what you mean by "fetch all of the aliases".
At the stage the candidates are being checked you will need to traverse up the DIT
looking for aliases unless the entry itself is an alias.  Is that what you mean?

> All this leaves out is cycle detection. However, I got a partial response
> from Wahl to some questions on the issue that leads me to believe that
> cycles are non-issues:

By cycles I assume you mean loops? They are discussed in
http://www.ietf.org/internet-drafts/draft-byrne-ldap-alias-00.txt it states that

             During the dereferencing of aliases, a loop is detected if the
             server visits the same alias entry more than once. In this
             case a data integrity error has occurred and the server MUST
             return an error of 'aliasProblem'

> > From Mark.Wahl@INNOSOFT.COM  Mon Oct 19 15:19:34 1998
> >
> > You should definitely look at X.501, X.511 and X.518 in addition to X.521.
> > There is much more information on how aliases operate which we simply reference
> > from LDAP.
> >
> > > Another question is how do you report an error? I'm assuming that the
> > > case of an alias pointing to itself is an error. Is it an "alias
> > > problem" or an "alias dereferencing problem?" Should it be an error to
> > > create entries like this in the DIT in the first place?
> >
> > I don't think an alias to itself is an error, though it is not useful.
> > The target object exists and is searchable.
> >

Well, dereferencing an alias to itself seems to me a problem if loop detection is not
in place and the error reported since aliases are supposed to dereference to the end
point.  This means that if the dereferenced alias is itself the code is obliged to
dereference that, ad infinitum.  The only time I can see this not being a problem is if
the alias is either dereferenced once, there is a special case to itself (in whichcase
you can still make loops), or you don't dereference.

> > aliasProblem: An alias has been dereferenced which names no object.
> > aliasDereferencingProblem: An alias was encountered in a situation where it
> > was not allowed or where access was denied.
>
> I'll have to track down his pointers today and see what the X.500 docs have
> to say about cycles.
>
> There's also the issue of the ACL, but I don't see how to fit that in
> here--I just haven't bothered to wade through that chunk of code yet.

--
Will Ballantyne     GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca