[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Alias dereferencing

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.

Hm, looks like you're right. This can easily be fixed in back-bdb, someone should file an ITS.

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.

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.

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.

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.

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.

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