Re: Alias dereferencing

[Michael Reiher <reiher@vidsoft.de>]

On Sunday 11 September 2005 09:30, Howard Chu wrote:
> Hallvard B Furuseth wrote:
> > No, that text is about the alias entry, not the entry which the alias
> > points at.
> >
> > This sounds like an OpenLDAP bug.  Look a few paragraphs above in the
> > models draft:
> >
> >       "The conversion of an alias name to an object name is termed
> >       (alias) dereferencing and comprises the systematic replacement of
> >       alias names, where found within a purported name, by the value of
> >       the corresponding 'aliasedObjectName' attribute.  The process may
> >       require the examination of more than one alias entry."
> >
> > Note that replacement is not just done when the name itself is an alias,
> > but also with aliases within the name.
>
Ahh, yes, that's exactly what I meant.

> Hm, looks like you're right. This can easily be fixed in back-bdb,
> someone should file an ITS.
>
Will do, if I don't need special priviledges for that.

> >> The other issue is, that it also doesn't seem possible to resolve
> >> aliases pointing at entries in a different backend
> >
> > ...and that's an old limitation in OpenLDAP, which if I understand
> > correctly it would be quite a bit of work to fix.
>
> It is not a limitation per se, but a conscious design choice. Alias
> behavior in LDAP (as specified in RFC2251) adopts the definition in
> X.501. Accordingly, the aliasedObjectName attrbiute may only contain a
> DN. The DN does not have to point to an object that exists, but if it is
> to be dereferenced successfully it obviously must point to an entry
> within the DIT. Since there is no URI info attached, (unlike a referral) 
> it obviously cannot point to an entry stored in some other DIT on some
> other server; it must point to a location within the same naming context
> as the alias entry itself.
But you don't need any URI info to access another DIT within the same server 
process. So I don't really see the advantage here, of disallowing aliases 
between DITs within the same server process. Except maybe difficulties in 
caching or something. But sometimes it helps a lot if something is possible, 
and speed is not so important. Who is concerned about speed probably 
shouldn't use aliases too much anyway. This is from my pragmatic point of 
view. 

>
> Note that by default, slapd treats separate backends as separate DSAs
> with totally independent DITs. (This is the design choice I was
> referring to.) Therefore, since those DITs are independent, aliases may
> only be resolved within the same backend.
>
Ok, I understand that reasoning. Though, from my intuition this seems like an 
artificial barrier. But maybe I'm missing some background info.

> Once again - not enough information has been presented re: why this
> particular approach is needed. Most sites should only need a single DIT,
> and thus a single backend. And sites that need to isolate data into
> separate DITs generally don't need to transparently refer to one DIT
> from another.
>
Well, reality is different, as often. This has partly historical reasons. We 
used different suffixes within a single ldbm backend (with 2.0.x) up to now. 
Now we switched to bdb and thus had to separate them into different 
databases, one for each suffix. As the historcal reasons aren't so important 
anymore we could even merge everything into one big tree, but that would 
imply various changes in code and scripts, or converting of databases at 
client sites. So we'd rather avoid that. The idea was to still be able to 
link everything together. For instance in order to be able to do a single 
search operation over all trees. And the easiest way would have been, if it 
were possible to use aliases from one tree to the others. If not, perhaps it 
would have been relatively easy to implement. But this has low priority, and 
referals will probably do here as well (not for search though, AFAICS). I 
just associated them with being used only for access to remote servers, while 
aliases are used for access within one server. Which was not quite right, 
obviously.

> >>> Now, if I'd want to implement this, i.e. to a) transparently handle
> >>> aliases
> >>
> >> It would be a mistake to implement (a) since you'll have no way to
> >> specify when you want to Modify the alias entry itself, vs what the
> >> alias points to.
> >
> > No need, since "subordinates of aliases" are not needed, just aliases
> > pointing at non-leaf entries.
>
> Well, this particular discussion is moot, since dereferencing is only
> defined for Search operations. E.g., see RFC2251 section 4.6, Modify
> Operation:
>
>    Parameters of the Modify Request are:
>
>    - object: The object to be modified. The value of this field contains
>      the DN of the entry to be modified.  The server will not perform
>      any alias dereferencing in determining the object to be modified.
>
> So implementing this feature would be a direct violation of the LDAP
> specification.
>
Err, yes, you right. It was more about the search operation anyway. I just 
thought, it might be handy at other places as well, but did not think about 
that there is no deref infratructure for anything else but search. So scratch 
this.


> >>> and b) support references to other backends.
> >>
> >> It would be a mistake to implement (b); that is already the purpose of
> >> referrals.
> >
> > It might be a mistake because of the mess I described above, but as far
> > as I can tell not because of referrals.
> >
> > draft-ietf-ldapbis-protocol-xx.txt defines referrals to be for
> > references to _other_ servers.  A server referring to itself seems to
> > be abuse of referrals, at least as far as the standard is concerned.
>
> No, you're just using sloppy terminology. Referrals point to information
> in other DSAs. Each backend in slapd is its own DSA, so referrals are
> precisely the correct feature needed to implement these references.
>
Hmm, ok, I see. But then doesn't for instance backend_group() also violate 
this paradigm? Afterall when it is called through access_allowed() from within 
a certain backend, it uses select_backend() to fetch groups with different 
suffixes. So there is cross backend access (and please don't remove that 
now ;).

Greetings

Michael