Re: aliased bases

[Robert Streich <streich@austin.apc.slb.com>]

> Robert Streich wrote:
> 
> > I spent some time looking over the code this weekend and it looks like it'd
> > be a fairly serious rewrite to put this above the back-end. The slapd code
> > just hands all of the search parameters over to the back-end code. You'd
> > have to rewrite the slapd search and all of the back-end searches. More
> > than I feel like taking on at the moment.
> 
> Yes, you're right.  I've just looked over that part of the code and there seems to
> be no way to issue an internal query.  That makes it pretty much impossible to
> implement general aliasing without changing the back-ends.    I had hoped to use
> the result layer to filter and translate aliases but cannot travel up the DIT
> without an internal query method.
> 
> I took a look at the ldbm back-end and you would need to alter both the dn2entry
> (for dereferencing the suffix) and search parts (for the target).
> 
> As an exercise I've implemented simple general aliasing for the ldbm back-end.
> The aliasing will do substitution of target entries but does not currently check
> the DN for any aliases within it.   I will put that in when I have some time (or
> you could?).  Also, I did not flesh out the different deref options (only "always"
> and "never") but will do so.
> 
> I will clean up the code and submit a diffs later.  Let me know if you would like
> a copy of the code in progress.

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.

That was the "easy" part. Since this is my first time in this code and
it isn't what you'd describe as "well-commented," I had a bit of studying
to do.

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.

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:

> 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.
> 
> 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.

bob


Robert Streich			streich@slb.com
Schlumberger			512-331-3318 (voice)
Austin Research			512-331-3760 (fax)